The New Device API (tm)

Hi,

as promised I worked out a draft for a new Device API. Let me list 
general requirements first:

user API:

* convenient traversal of devices, sessions and partitions
* advanced iteration (as provided by the old API)
* FS initialization, partitioning, low-level formatting
* ejection of removable media
* notifications on changes, including the following events:
  - mount point changes (renaming, moving)
  - mounting/unmounting
  - FS initialization, partitioning and low-level formatting
  - media changes
  - appearance/disappearance of devices

Like the old API the new one shall only deal with disk devices (`/dev/
disk/...'); mounted file images are ignored.


disk_scanner (kernel):

* traversal of devices, sessions and partitions (via modules/FS add-
ons)
* FS initialization, partitioning (via partition modules/FS add-ons)
* sending of notifications on FS initialization, partitioning


R2+: disc_scanner/whatever (kernel)

* partition resizing/moving (while being mounted 8-O)
* `virtual disk devices' (striped disk, composition of distributed 
partitions)
* a dedicated partition for meta data to support the former features 
and `journaling'
* ...


As already mentioned in earlier mails, in my opinion the R2+ features 
are rather orthogonal to what we plan for R1, and therefore there's not 
much to take care of to not create something that can't be extended 
with the listed features.

The disk_scanner as implemented seems to basically meet the 
requirements. The notification support still needs to be added, of 
course. Unless I'm mistaken, some notifications needed for the user API 
are not yet sended by the kernel, namely for low-level formatting, 
media changes and appearance/disappearance of devices. Unless there are 
reasons why this shouldn't be done, I would like to see them added to 
the OBOS kernel. For development and test under BeOS R5, at least the 
latter ones can be worked around by polling.

As already outlined in an earlier mail, I think, the best way do deal 
with the different change events is to bundle all the basic activity in 
one entity. In principle that entity could live in the user 
application, but since it will need to run at least one extra thread (a 
BLooper; maybe another one for polling), it is probably better to place 
it in a server, namely the registrar. The additional communication 
overhead should be acceptable, even if each method call would require a 
message exchange with the registrar (similar to the BMimeType 
implementation). If iteration turned out to be slow, optimizations were 
possible.

Before continuing, I should introduce the classes I envision for the 
API:

* BDiskDeviceRoster: The roster that knows about disk devices. It can 
be used to iterate through the devices and to register/unregister for 
notifications

* BDiskDevice: Replaces Device. Will provide similar functionality.

* BSession: Replaces Session. Will provice similar functionality 
(partitioning will be new).

* BPartition: Replaces Partition. Will provide similar functionality.

Regarding the naming: I find BDevice simply too general. BDisk would be 
fine in principle, but there may be potential for mixing it up with 
BVolume. BStorageDevice would be most accurate, but also a bit longer. 
:-P

Now that things have a name, let's come to the main design decision. 
Hrrmmmhh. (*clearing the throat* ;-) The question is, how static the 
data shall be. Be's implementation is maximally static: You have a 
DeviceList and as long as you don't call an update method explicitly 
the data remain unchanged. The entirely opposite strategy is to always 
return up to date information, i.e. two successive calls to a 
BPartition's GetVolumeName() could return different results.

Personally I find the latter approach inconvenient. One had to always 
check method results, since any method could fail at any time. Thus the 
error handling would certainly be rather painful. So I tend to favor a 
static strategy: A BDiskDevice and all its children should remain 
unmodified, unless explicitly updated. That means, one can use 
BDiskDeviceRoster to traverse a dynamic device list (GetNextDevice(), 
Rewind()), but a BDiskDevice retrieved that way would be static. 
BDiskDeviceRoster may of course also provide a method to get a snapshot 
of the current list...

With that as the premises, BDiskDevice, BSession and BPartition don't 
need to deviate API-wise that much from their predecessors. 
BDiskDeviceRoster on the other hand must differ heavily from 
DeviceList, especially with respect to the iteration.

Instead of writing a lot of words, I just let the headers speak for 
themselves:
  http://cs.tu-berlin.de/~bonefish/download/obos/DeviceAPI.zip

They are not finished -- there are a couple of things marked with 
`TODO', and for the implementation private methods and variable members 
certainly need to be added/changed -- but basically that's what I have 
in mind. Comments are of course very welcome.

CU, Ingo