[openbeosstorage] Re: My Usual Confusion

On Sun, 15 Jun 2003 14:41:43 -0700 Tyler Dauwalder <tyler@xxxxxxxxxxxxx
> wrote:
[...]
> > 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?

Yes, that's what I think, too.

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

The latter sounds very scary. Then we would lose the nice independence 
of partitioning and file systems. Given a DiskDeviceType.h type, the 
partitioning system should try its best to map it to an actual 
representation.

> > [...]
> > > > 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. 
> :-)

Exactly. :-)

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

OK.

[...]
> > > 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. 
> :-)

Hehe. :-)
Sure, if things get too worse we should think about refactoring, but 
currently it's still OK, I think.

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

Yes.

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

0x00 indicates an empty partition descriptor. All other values should 
be set to 0 by writing systems and ignored by reading systems 
(according to the specification I read). I wouldn't want to use it as a 
vehicle in our case.

[...]
> > > 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. :-)

I'll remove it.

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

OK, will be added.

CU, Ingo

Other related posts: