[openbeosstorage] Re: My Usual Confusion

> 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?

Hmmm. Yes, true, I guess, using the Type()+ContentType() system. That's 
messier than I had anticipated...

As I'll mention below, I think the ContentType()-only system does a 
much nicer (and equally effective) job:

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

BPartition:
ContentType(): "Intel Extended"
 
contains:

BPartition:
ContentType(): "BFS Filesystem"

> 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. 

No, the idea here was that child partitions would always be unformatted 
and empty, and initialization would then specify a type. E.g., to add 
an extended partition, one would create an empty partition, then 
initialize it to the type `intel extended partition', which would only 
be allowed if the parent were of type `intel partition map'. Further, 
if one initialized said partition to any other type, it would 
automatically become a primary partition instead. (I guess, technically 
speaking, you'd probably internally make it an unformatted primary 
partition by default, and upon initialization to `intel extended', you 
would convert it to an extended partition).

> 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).

To tell you the truth, I don't remember what `parameters' is for. :-) 
If one wanted to be able to specify the type of child partition at 
creation time, certainly that would be the way to do it. I think I 
preferred the idea of simply creating an empty partition and then 
letting the partitioning system decide at initialization time exactly 
what type it would be.

> 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?

Yes, it's a bit redundant and unnecessary.

> 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.

Yes, but that being the case, the parent-given type is really of no 
useful relevance (other than purely academic), as far as I can see. 
Disk systems don't care if they're being used on a primary partition or 
a logical partition. And one can decide if a partition is a primary or 
logical partition simply by examining the parent type and seeing if it 
is intel or intel extended respectively. This is why I originally had 
only Type() (which corresponded to our current ContentType()). 

The only argument I can think of for really needing our current Type() 
method is if we had a partitioning system that allowed the creation of 
different types of non-partitionable child partitions (i.e. two 
different types of intel primary style partitions). But I can't think 
of any good reason why such a feature would be offered. Further, I 
would guess/hope that in most cases, one could implicitly determine 
which of the types should be chosen, similar to the way primary vs. 
extended can be implicitly chosen. 

> 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.

True. Again, this is because I didn't intend our current Type() method 
to be needed at any point.

> 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?

Well, the question intended to be answered by the the 
SupportsXYZSystem() functions is not whether one can create a partition 
of a given type, but whether one can initialize an already existing 
child partition with the given disk system. The two functions together 
would be used to implement BPartition::CanInitialize(). I suppose the 
extra KPartition argument could still be useful, though. 

Btw, shouldn't it be `bool SupportsChildSystem(KPartition *parent, 
const char *system) const;' instead?.

Given my original intention to support empty child creation only, what 
then is really missing is something like:

bool SupportsCreateChild(KPartition *parent);

So, the question, I guess, comes down to how we want to specify the 
typing of child partitions from the parent partition's point of view. 
My original intent was to do this implicitly. As mentioned, if done 
this way, the current Type() member is just a type string that tells 
the user some potentially interesting, but otherwise not particularly 
useful information. And it has no correlation to disk systems.
 
The other way to do it would be to allow specification of the partition 
Type() at creation time, which means some more supporting code, and 
also a way to pass Type() values around. I don't like that idea, unless 
you have some compelling arguments otherwise. I don't really think we 
need it, and don't currently think we'd gain anything by going that 
route.

As to Type() and ContentType() specifically, I'm also no longer 
convinced that Type() is all that necessary. I'd just as soon get rid 
of it and rename ContentType() back to Type().

> 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.

Having seen the way types would need to laid down using the 
Type()/ContentType() system, I'd actually much rather just go back to 
using Type() only (semantically like our current ContentType()) than do 
this. Though a GetDiskSystem() call could still be useful.

What do you think? :-)

-Tyler

Other related posts: