FreeLists / openbeosstorage / [openbeosstorage] Re: Kernelland Draft Headers

["Ingo Weinhold" <bonefish@xxxxxxxxxxxxxxx>]

On Tue, 10 Jun 2003 03:15:34 +0200 CEST "Axel Dörfler" <axeld@pinc-
software.de> wrote:
> "Ingo Weinhold" <bonefish@xxxxxxxxxxxxxxx> wrote:
> > On Mon, 09 Jun 2003 18:49:55 +0200 CEST "Axel Dörfler" <axeld@pinc-
> > software.de> wrote:
> > The point is, that the `internal' short name is the file (or 
> > module) 
> > name -- as opposed to the one, that was planned until now, which 
> > should 
> > be more user friendly. That's the reason, why we want to make it 
> > available in the userland API, too. :-)
> 
> Okay, cool. But right now, you could define another file system name 
> in 
> fs_read_fs_stat() (if you feel like it :).

Though that's not what one should do, I suppose.

> > Mmh, maybe Name() + DescriptiveName() is better than ShortName() + 
> > Name(), after all. Grr, naming is always the most complicated part. 
> > ;
> > -)
> 
> Definitely! BTW the Media Kit uses "short_name" vs. "pretty_name"; 
> but 
> I think Name() would be okay. I have no real feelings towards 
> DescriptiveName() vs. PrettyName(), but I think consistency would be 
> great - but of course, descriptive_name could already be used, too - 
> I 
> have just not checked :-)

OK, I'm also fine with Name() + PrettyName(). A grep through the system 
headers brought up no relevant occurence of descriptive.

> > > If we are about to change the access pattern to file systems in a 
> > > way 
> > > like this, I would rather get rid of that special architecture 
> > > and 
> > > make them modules, like (almost) everything else.
> > > Then, bfs could have a module name "fs/bfs/v1" or whatever :-)
> > Sounds good.
> 
> So you would welcome a change like this?
> We will also make drivers modules with the new driver API (optional, 
> of 
> course), so that would just be another step to a more consistent 
> concept.

Oh, I thought, you were talking about R2 plans. But yes, since the 
interface won't be compatible with R5 add-ons, we could as well do that 
now -- it's even better now than later, to avoid breaking things then. 
Unless there are issues that I don't see, I'd say just go ahead.

CU, Ingo