FreeLists / openbeosstorage / [openbeosstorage] Device API / DriveSetup AddOns

["Ingo Weinhold" <bonefish@xxxxxxxxxxxxxxx>]

Howdy,

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

I've experimented a bit with a virtual drive driver (based on sources I 
got from Marcus) and here is what I learned from it:

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

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>_<partition number>' close to the `raw' device of the 
driver.

So what and where is this entity? 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_setup/{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.

Here's a list of what suspicious function symbols I found in such add-
ons:

fs:
ds_fs_flags
ds_fs_id
ds_fs_initialize

partition:
ds_get_nth_map
ds_partition
ds_partition_flags
ds_partition_id
ds_partition_name
ds_update_map

session:
ds_get_nth_session

Wildly grepping the strings of DriveSetup and the files in /system and 
for these names, I found out, that libbe uses all but ds_fs_flags and 
ds_partition, and DriveSetup all but ds_fs_flags. libbe contains the 
device API and thus this is not surprising. The R5 DriveSetup 
apparently doesn't use the device API, but deals with the add-ons 
directly.

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.

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.

Anyway, back to the original problem: The device API carries out its 
fundamental functionality through the DriveSetup add-ons. Since all I 
know about the add-on API are the names of the functions, and I'm a bit 
stuck with objdump and a lack of x86 assembly knowledge, there's not 
much I can do for now. Furthermore there are some other missing bits, 
e.g. what function/syscall is to be used to publish a device for a 
partition (Partition::AddVirtualDevice()).

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.

CU, Ingo