[openbeosstorage] DiskDevice API v2.0
- From: Tyler Dauwalder <tyler@xxxxxxxxxxxxx>
- To: openbeosstorage@xxxxxxxxxxxxx
- Date: Sun, 23 Mar 2003 23:11:11 -0800
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? :-)
Other related posts:
