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

[Tyler Dauwalder <tyler@xxxxxxxxxxxxx>]

On 2003-06-17 at 11:32:51 [-0700], Ingo Weinhold wrote:
> 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.

So then, shouldn't the partitioning system be able to pick a type at 
initialization time like I originally intended?

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

Then perhaps the optional parameter would be a good idea.

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

Okay, fair enough.

So, I'm not sure where we stand on things now. :-) Are you planning on 
combining child creation and initialization, or... 

-Tyler