Re: Device API / DriveSetup AddOns

> > 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 :-)

I'm afraid not much.

> > 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

If we wanted to build the device API on top of R5's libroot and don't 
have knowledge about the private API we needed to use, then, I would 
say, it's not possible to do that.

I was under the impression, that we want to start with libroot and the 
DriveSetup (DS) add-ons as a base, but as it seems to me, you intended 
to start with the stuff at the very roots. :-P

> > 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).

Yep.

> > 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

I found a bit of documentation, that clarifies the process -- a bit of 
the DS add-on interface and even the syscall for publishing a logical 
device (B_SET_PARTITION) are described: Be Newsletter, Volume II, Issue 
23, `Getting Mounted'

The partition add-on does only report the offset and the size of the 
partition. The user application has to call B_SET_PARTITION to publish 
the device for the partition.

> > 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

Well, "mysterious entity" would probably fit better. What confused me 
in the first place was, that I expected the kernel to be the one 
responsible for recognizing disk drive like devices, analyzing their 
session/partition layout and publishing respective entries in `/dev/
..'. For it didn't happen to be the kernel and no daemon either, I 
began to find the matter mysterious. And that there actually isn't even 
such an entity, but only user-level applications doing this through the 
device API (or in the case of DriveSetup manually) was indeed quite 
surprising for me.

> > 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.

That's fine with me.

> > 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.

Yep, sounds reasonable. If possible (and I believe it is), I think, it 
would be a good idea to write a user-land implementation of the kernel 
API, so that we can develop the add-ons and the C++ device API under 
R5.

> I think we should continue to use an add-on based approach, but the 
> add
> -ons should be kernel add-ons.

Definitely.

CU, Ingo

PS: Do I remember correctly, that we use a fair amount of C++ in the 
kernel (even virtual functions!?)? Doesn't that call for a nice C++ API 
for the DS add-ons? :-P

PPS: Axel, didn't you plan to write a "C++ in the kernel" newsletter 
article? :-P

PPPS: I have never played with sessions/partitions before, so, if you 
have any helpful links, don't hesitate to throw them at me. ;-) I 
guess, for hard disks the fdisk sources wouldn't be too bad a point to 
start at. CDs, floppies,...?