Re: The New Device API (tm)

> "Ingo Weinhold" <bonefish-CFLBMwTPW48UNGrzBIF7/[email protected]> wrote:
> > > Shouldn't there better be a notification that the partitions are 
> > > gone
> > > =3D3F 
> > > The reason why they are gone is okay to know, but not the other 
> > > way 
> > > around; knowing the reason and having to find out about the 
> > > consequences yourself, right=3D3F
> > That's a good point. I will change the notification events to 
> > something 
> > like B=5FDEVICE=5FPARTITION=5F{ADDED,REMOVED} then.
> 
> Yes, that would be nice (even with a "reason" field or something like 
> this).

Good idea.

[...]
> > > Right; and we can change the internals anyway. Perhaps we 
> > > shouldn't 
> > > make the current APIs public now anyway, so that we don't have to 
> > > support them later on, if we decide to drop/replace them.
> > No, the API should definitely not be public in R1. I guess, now I 
> > also 
> > remember, why I put the headers for the session/partition/fs module 
> > API 
> > in the `private' subtree. :-) Since I don't think, they should be 
> > public in the first release -- but it seems that `headers/os/
> > drivers' 
> > is the correct place anyway.
> 
> headers/os/drivers is for kernel add-ons only - so that might be a 
> good 
> candidate, yes :-)
> Perhaps we should even rename the fs=5Fdevice.h header to disk=
> 5Fscanner.h 
> in the os/kernel/ directory=3F

Yes, it's a bit misnamed, as it has little to do with file systems.

> We could keep the headers in that directory (but don't have to, of 
> course), and add a big disclaimer expressing their beta nature.

Right.

> [...]
> > > > Mmh, if you're not in a hurry...
> > > Not at all, there are still more urgent issues, I think :-)
> > Hehe. And skiing of course. ;-)
> 
> Oh, yes! Tomorrow I'll be heading to Switzerland!

Enjoy  yourself! And try to not break to many bones! ;-)

[...]
> > Mmh, isn't mount() part of some POSIX standard=3F What we could do, 
> > is 
> > to 
> > keep it, but let it check whether the supplied void* parameter 
> > (considering len too) looks like a string, and, if it does, pass it 
> > to 
> > the new API.
> 
> No, mount() is not part of the POSIX standard, it just happens to be 
> part of almost every OS (at least AFAICT).
> We could also keep the current scheme and let the file system decide 
> if 
> it wants to use the (to be extended) driver=5Fsettings API - we could 
> just encourage but not enforce its usage.
> But I am not yet sure why we shouldn't enforce it, just for the sake 
> of 
> consistency and simplicity for the user.

I'm fine with that. Considering how few application use mount(), and 
that the ones I think of are rewritten anyway, breaking compatibility 
won't do any harm.

> [... find=5Fdirectory]
> > > If it already asks for the file system name, it needs one kernel 
> > > call 
> > > to do that - if it would replace that with the call to get the 
> > > directy 
> > > from the file system directly, that wouldn't change much, I 
> > > think.
> > You're absolutely right. It currently gets a fs=5Finfo from the 
> > kernel, 
> > so it wouldn't make any difference performance-wise.
> 
> Of course only if it hasn't have to make this call anyway to get the 
> mount point or whatever.

This depends on how the interface (an ioctl() probably) for getting the 
directory looks like, i.e. whether it returns an absolute or relative 
path...

> Well, we'll see. I don't think that 
> find=5Fdirectory() is time critical anyway :-)

Not really. :-)

> > Regarding the further proceeding: I will have some time on the 
> > weekend 
> > and I plan to check in the proposed headers (incorporate the 
> > discussed 
> > changes before, of course), doxygen-document the API -- due to the 
> > non-
> > fixedness of the API maybe not too exhaustive -- and start with the 
> > implementation.
> 
> Sounds good, although, as I mentioned several times now, I am skiing 
> :-
> ))

No worries. This was merely my own work plan. :-)
If you feel the urge to have a look at it, when you're back, you're of 
course welcome do to that. :-)

CU, Ingo