[openbeosstorage] My Usual Confusion
- From: "Ingo Weinhold" <bonefish@xxxxxxxxxxxxxxx>
- To: "Storage Kit" <openbeosstorage@xxxxxxxxxxxxx>
- Date: Fri, 13 Jun 2003 00:17:42 +0200 CEST
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:
