FreeLists / openbeosstorage / [openbeosstorage] Re: My Usual Confusion

[Tyler Dauwalder <tyler@xxxxxxxxxxxxx>]

> > > 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.
> 
> That's what I thought, too. Though, I obviously had another notion of
> `partition' in mind. Like contiguous space of a certain size located 
> at
> a certain position. Initialization would only affect this space.

No, we're thinking the same thing. I shouldn't have said `empty' when I 
only meant `unformatted' all over again. :-)

> > > 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. 
> > :-)
> 
> It may very well have been proposed by me. :-)

Probably was. :-)

> The parameters will specify... err... parameters for the disk system.
> In case of a file system, those may be block size, support for 
> optional
> features (e.g. default indices), and the like.

Okay. :-)

> > 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.
> 
> The problem I see here is, that the parent partitioning system (also)
> has to take action, when the child partition is initialized. More
> precisly, the parent system has to know, what to do for a certain 
> child
> disk system. The advantage is, that we would get consistency between
> the type specified in the partition descriptor and the type of the
> system the partition actually contains.

That's a good point.

> [...]
> > > 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.
> 
> As a matter of fact the intel partitioning scheme knows three extended
> and dozens of primary partition types. 

Crap, I forgot about that... :-)

> So, it is indeed a not
> completely trivial task to pick the right type given a child disk
> system. Since, as I believe, more or less all partitioning systems
> provide an identifier for the content type of a partition, something
> similar has to be done for all partitioning system modules.

Well, we'll need a way to map DiskDeviceType.h types to partition 
types, anyway, correct? I mean, shouldn't there be a one to one mapping 
of DiskDeviceType.h types to partition types? Either the partitioning 
systems need to know how to map their types given a DiskDeviceType.h 
type, or the file systems need to know their correct partition types 
for each partitioning system... 

> [...]
> > > 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?.
> 
> Then the important information, which child partition is meant, is not
> provided. Suppose we want to allow only one extended partition (which
> isn't an uncommon constraint), (re-)initializing the already existing
> extended partition should succeed, while it should fail for all other
> partitions.

Okay, and you can get the parent via Parent()... I'm up to speed now. 
:-)

> > Given my original intention to support empty child creation only,
> > what
> > then is really missing is something like:
> > 
> > bool SupportsCreateChild(KPartition *parent);
> 
> Well, ValidateCreateChild() could be used, but maybe a dedicated
> function would be better.

If we went with that, I think I would prefer a dedicated function, 
since we have them for other ops.

> > 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.
> 
> Right.
> 
> > The other way to do it would be to allow specification of the
> > partition
> > Type() at creation time, which means some more supporting code,
> 
> I wouldn't bet on that. The magic to be implemented to support the
> implicit typing might turn out to be rather complex. If I would be
> forced to guess, I'd say even quite a bit more complex than what would
> be needed for the other approach.

Okay. 

> > and
> > also a way to pass Type() values around.
> 
> We pass so many things around, I don't think one more does matter that
> much. :-)

I am just resistive to parameter/function count increases, that's all. 
:-)

> > 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.
> 
> I have at least some arguments to be evaluated.
> 
> 1) As mentioned above, the parent disk system will be involved (and 
> the
> parent partition modified), when a child is being initialized. The
> parent system must known all possible child types. Not only child disk
> systems, but child types. The different flavors of FAT for instance
> result in different intel partition types, while there's probably only
> one FAT file system module. I'm afraid, that means analyzing the
> initialization parameters for the child disk system, which I don't 
> like
> that much. KDiskSystem::ValidateInitialize() could get an optional
> parameter, through which the corresponding type is returned. Then this
> type could be passed to the parent system instead.

By `corresponding type', are you meaning the DiskDeviceTypes.h type? 

> 2) Implementation-wise things would be less uniform, since the
> partitioning system would have to apply changes to the parent shadow
> partition on an initialization request from userland.

Okay.

> 3) Wouldn't DriveSetup be less convenient and/or powerful? I suspect,
> it won't be possible to e.g. create a ReiserFS partition, but don't
> initialize it (the add-on may be read-only anyway). This is even a bit
> inconsistent, since in the intel case the newly created partition will
> have a certain type (unless there's a value for `undefined', which I
> haven't seen till now). 

How about 0xo0? Linux treats it as unformatted, Windows ignores it, and 
partition magic treats it as unpartitioned space.

> We could consequently force the user to always
> initialize a newly created partition, but this would obviously be more
> restrictive.

But, I'll admit, an arguable restriction. 

> > 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().
> 
> I see no problem with that.

Hooray. :-)

> > > 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.
> 
> I think, there is a difference between the disk system's pretty name
> and the partition's type. E.g. we have several flavors of FAT, but 
> only
> one FS module handling all.

Okay, I see what you're saying now. I also was working under the 
assumption that type names could be mapped functionally to disk system 
names, but I finally see why they can't. So yes, we definitely need 
GetDiskSystem(). :-)

-Tyler