[openbeosstorage] My Usual Confusion

Howdy,

I just want to make sure, that I'm not running into a totally wrong 
direction. Here's a small example for illustration: Given a hard disk 
containing one extended intel partition containing one logical 
partition being BFS formatted, the object hierarchy should look like 
this:

BDiskDevice:
Type():        "Hard Disk Media"
ContentType(): "Intel Partition Map"

contains:

BPartition:
Type():        "Intel Extended Partition"
ContentType(): "Intel Extended Partition" ???

contains:

BPartition:
Type():        "Intel Logical Partition"
ContentType(): "BFS Filesystem"

True, or shall the content type of the extended partition be something 
different?

Assuming that I'm more or less right, is there really a one to one 
correspondence of types and disk systems, as I assumed until a few 
minutes ago? IIRC, that was the idea for the BDiskSystems -- it was 
intended that using Supports{Child,Parent}System() DriveSetup could 
offer a choice child partitions of what types can be created on a 
partition -- but somehow this concept hasn't made it into BPartition:

status_t CreateChild(off_t start, off_t size, const char *parameters, 
BPartition** child = NULL);

Neither a type nor disk system can be specified. If that is no mistake, 
it can only mean, that the `parameters' shall contain the information 
about the partition type to be created. This makes quite a bit of 
sense, since the disk system for (the content of) a partition should 
know very well, child partitions of which types can be created on it 
(e.g. primary or extended partitions on an intel partition map hard 
drive, or only logical partitions on an extended one).

If there should really be a one to one correspondence between types and 
disk systems, then I wouldn't see, what the purpose of the disk systems 
for the Type() would be. At neither of the three levels of the example 
they seem to have much functionality. E.g. if one wants to resize the 
logical partition, three systems would be affected: The "Intel Extended 
Partition" system of the parent partition, the child's "Intel Logical 
Partition" system, and its "BFS Filesystem". But what has the second 
one to do?

What seems to be intended for BPartition and what IMHO also makes most 
sense, is that a partition has a parent-given type and it can be 
formatted with any disk system. Which therefore corresponds to the 
ContentType(). When creating a child partition, the parent assigns a 
type to the child, but its contents will be uninitialized until 
initialized with a disk system. Hence there is a ContentType() - disk 
system correspondence, but Type() is just a type string.

Supposing, that we indeed want it this way, then the BDiskDevice 
interface has a few problems. Namely: Supports{Child,Parent}System(). 
The questions that these methods could answer given the other approach 
(like: Can I create a logical partition on an extended one, or a BFS on 
a logical one?), can not longer be asked, since the disk system 
corresponding to Type() is missing.

To fix the problems, basically the concerned partition needs to be 
supplied as well:

        bool SupportsChildSystem(KPartition *child, const char *system) 
const;
        bool SupportsParentSystem(KPartition *child, const char *system) 
const;

`child' would be the partition, which shall be initialized with a disk 
system, `system' the respectively other disk system. Instead we could 
as well drop both methods, since BPartition::CanInitialize() can as 
well have both conditions checked in the kernel. Or we also introduce a 
BDiskSystem::CanInitialize(BPartition*).

IsSubSystemFor() should still be OK, I think.

Thoughts?

CU, Ingo

PS: How about a BPartition::GetDiskSystem(BDiskSystem*)? Then 
BPartition::ContentType() wouldn't even need to have any strong 
relationship with the disk system's (pretty) name.

Other related posts: