[openbeosstorage] Re: My Usual Confusion
- From: Tyler Dauwalder <tyler@xxxxxxxxxxxxx>
- To: openbeosstorage@xxxxxxxxxxxxx
- Date: Tue, 17 Jun 2003 12:07:51 -0700
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
Other related posts:
