[openbeosstorage] Re: Device API / DriveSetup AddOns
- From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
- To: openbeosstorage@xxxxxxxxxxxxx
- Date: Mon, 09 Dec 2002 20:31:11 +0100 CET
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.
Other related posts:
