[openbeos] Re: DiskSetup
- From: Ingo Weinhold <bonefish@xxxxxxxxxxxxxxx>
- To: openbeos@xxxxxxxxxxxxx
- Date: Sun, 27 Feb 2005 14:25:34 +0100
On 2005-02-27 at 13:32:33 [+0100], Axel Dörfler wrote:
> Daniel Furrer <daniel_furrer@xxxxxx> wrote:
Mmh, I didn't get the original mail.
> > I just had a quick look at the DiskSetup. It seems like it is one of
> > the
> > few preference apps that are still very much in the first
> > stages of development. Anyway, I was wondering how the DiskSetup is
> > supposed to get its information about the disks&partitions.
> > I didn't find any public API calls that would allow for an easy way
> > to
> > interact with these things - but there seem to be some classes
> > that could help in the (private part? of the) storage kit.
> > Could anyone explain a bit how this is supposed to work?
In BeOS recognition of the boot partition is built into the kernel
(respectively boot loader), while everything else is done via DriveSetup
add-ons in userland. Besides DriveSetup those add-ons are also used by
mountvolume and by a private API (DeviceMap), which the Tracker uses. The
add-ons implement an interface for scanning/identifying partitions and
provide a GUI for manipulating partitions (the one you see in DriveSetup).
Our approach to dealing with partitions is quite different from Be's. It is
kernel-based and generic. Kernel-based means, that besides file system
kernel modules we also have partitioning system modules and a kernel
subsystem, the DiskDeviceManager (DDM), that implements all operations on
partitions (using the file/partitioning system modules to perform specific
tasks). The functionality is exported to the userland via syscalls and a
thin C++ API (thin in that method implementations often don't do more than
invoke a respective syscall; it's very feature-complete though) is provided
(see headers/private/storage/Disk*.h).
The center of this DiskDevice API is the BDiskDeviceRoster class. It can be
used to iterate through all installed disk devices (HD, floppy, CD, etc.)
and the partitions they contain, as well as through all known disk systems
(i.e. file/partitioning systems). The BPartition class exposes most of the
manipulation features (creation, moving, resizing, formatting).
Our approach is generic in that you can use this API to manipulate
partitions without actually knowing anything about their type and contents.
Nevertheless it is possible to change disk system specific parameters, too.
A set of userland add-ons (also accessible through the BDiskDeviceRoster)
will allow anyone to provide a GUI for editing those parameters.
> I think there is little point in recreating DriveSetup as is and at
> this point:
> 1) we have a completely different API than BeOS had (Be's was never
> made public anyway)
> 2) our userland disk device API doesn't work yet IIRC (kernel one does,
> though)
In fact the userland API is virtually completely implemented (save the
add-on part for edition disk system parameters). Still missing is the write
and notification support in the kernel, though.
> 3) as our API is a lot more mature and powerful than Be's was, the
> future DriveSetup has a lot more things it can do, and thus, I would
> like to see a new GUI as well
> 4) IIRC Stephan Assmus volunteered more or less officially and
> willingly to do this. Dunno if he's still up to it, though
Well, actually more unofficially. :-)
Anyway things are not really in shape to develop and test something yet.
That is one could write and build (due to the complete userland API), but
testing is not really possible.
CU, Ingo
Other related posts:
