Re: Device API / DriveSetup AddOns

Hi Ingo,

> I've been researching a bit more and I come to believe, that either 
> there's something nice and dandy I'm overlooking or that it is 

Although I've read the whole mail, what do you thing you are 
overlooking=3F :-)

> virtually impossible to implement the device API on top of Be's 
> libroot. At least not without getting more information about some 
> private API parts. (BTW, isn't libroot derived from glibc and doesn't 
> that mean that (respecting the LGPL) the sources had to be 
> published=3F)

They have released it, yes, but I don't think it would be of great 
help, unless you explain how it could be impossible=3F

> Per drive a mass storage driver publishes a device (usually /dev/.../
> raw) that represents the drive as continues storage readable and 
> writable like a file implementing some additional ioctls. (For SCSI 
> drivers things seem to work a bit differently -- CAM, read/write 
> doesn't work.)

If possible, we should make sure that read/write will work for SCSI 
devices, can't imagine how else it could work (well, you probably can 
use readv/writev instead).

> The driver doesn't need to know about sessions/partitions/FSs; 
> another 
> entity handles this. This entity reads the respective information 
> from 
> the drive (via the driver, of course) and publishes devices named 
> like 
> `<session number>=5F<partition number>' close to the `raw' device of 
> the 
> driver.

Exactly.

> So what and where is this entity=3F Putting this question aside for a 
> second, I would naively suspect, that, whatever it is, it uses the 
> DriveSetup add-ons (`/system/add-ons/drive=5Fsetup/
> {session,partition,fs}
> /*'). The session add-ons can deal with sessions on a drive, the 
> partition add-ons know about partitions on sessions and the FS add-
> ons 
> can identify/initialize a FS on a partition.

The logic for this is in the add-ons, it's currently working like this 
(so I imagine, at least):
1. the DriveSetup add-on loads the partition table and parses it
2. it writes the new partition info via ioctl() to the raw device, if 
it has to; this will create a new device x=5Fy alongside the raw entry
3. that new x=5Fy device is now regularly mounted

> So back to the question, what the magical entity is. I would say, 
> it's 
> the user of the device API, i.e. usually the auto mounter of the 
> Tracker and, if running, also DriveSetup (and mountvolume which uses 
> the device API). That suspicion is supported by my experience that 
> the 
> devices for the partitions aren't published when neither Tracker nor 
> DriveSetup are running.

I kind of don't get the part with the magic entity=3F What else should it 
do=3F

> For the kernel does neither use the device API nor the DriveSetup add
> -
> ons, there is certainly built-in functionality to deal with session/
> partition/FS recognition. Don't know, if one could avoid that code 
> duplication.

That's one thing I want to change; the kernel must have some kind of 
knowledge about sessions and partitions, because it can boot from a BFS 
partition or session on disk. It doesn't do anything else when it's 
running, though.

> Conclusion: Either someone pulls the missing information out of a 
> hat, 
> or we 1) have to start more or less from the scratch with the drive 
> setup add-on API and 2) need to postpone the final implementation of 
> the device API until our kernel features all the functionality we 
> need.

I would be for 1.5) ;-)
I think the kernel should be independant of libbe.so and the drive 
setup add-ons - it should be able to recognize partitions and sessions 
all the time, it shouldn't play dumb in this regard after having 
booted.
So the first thing would be do design a kernel API that makes 
implementing everything needed for the private Device API possible. I 
thought we would design that API together, off-loading most of the real 
work to the kernel. Then, the Device API could be written relatively 
easy from scratch.
I think we should continue to use an add-on based approach, but the add
-ons should be kernel add-ons.

Adios...
   Axel.