FreeLists / openbeosstorage / [openbeosstorage] DiskDevice API v2.0

[Tyler Dauwalder <tyler@xxxxxxxxxxxxx>]

Hi guys,
                         
Here's my proposed header changes for the Disk Device API 
incorporating a more general partitioning scheme:

http://www.dauwalder.net/DiskDeviceAPI_v2.0.zip

BPartition now provides the base functionality used for any 
contiguous chunk of data. Each BPartition has a char* Type() that 
identifies the system it's formatted with (be it a partitioning 
system or a file system). 

BDiskDevice is a subclass of BPartition that provides the device 
specific functionality. Each device also has an associated char* 
DeviceType() that identifies what sort of device it is. 

So, if you had a hard drive with an intel partition map containing a 
single BFS primary partition and an extended partition that contained 
a FAT32 partition and another BFS partition, things would look 
something like this:

---------------------------------------------------------------------
                   BDiskDevice
                   - DeviceType: [Hard disk]
                   - Type: [intel partition map]
---------------------------------------------------------------------
--------------------  -----------------------------------------------
   BPartition                   BPartition
   - Type: [bfs]                - Type: [intel extended partition]
--------------------  -----------------------------------------------
                      ------------------------ ----------------------
                           BPartition               BPartition       
                           - Type: [fat32]          - Type [bfs]
                      ------------------------ ---------------------- 
 

Aside from stripping out all the BSession related stuff, I also made 
the partition management code a little more specific. It seemed to me 
that the method we were using for partitioning was pretty general, 
i.e. for every partitioning system we support, we'd have to write a 
new set of parameter editors to support the entire partitioning 
process (correct me if I'm wrong here). Since the whole system is now 
more general, it seemed to me it would be reasonable to support the 
general set of partition management functions (move, resize, create, 
delete, edit parameters) in the API itself. I'd like to see our 
DriveSetup replacement offer a nice, unified UI for partition 
management a la PartitionMagic, and I think supporting partitioning 
in the API itself will make it easier for new partition systems to be 
supported transparently.

So, the aforementioned operations are all supported by the API now, 
along with partition initialization. I also made all such operations, 
many of which will probably tend to be rather lengthy processes, into 
functions of the form:

int32 operation([args], BMessenger progressMessenger)

The idea is that the functions will first do some checking to make 
sure the operating can be performed. If so, they'll spawn a new 
thread to perform the task, and return a unique id for the job. The 
job then can send progress update messages containing the job id to 
the specified BMessenger, where they can then be passed on to the 
user somehow so they know what's going on.

I think that's pretty much it. I now await your comments. :-)

-Tyler

p.s. How's the laptop hunt going, Ingo? :-)