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

["Ingo Weinhold" <bonefish@xxxxxxxxxxxxxxx>]

On Tue, 17 Jun 2003 12:07:51 -0700 Tyler Dauwalder <tyler@xxxxxxxxxxxxx
> wrote:
> 
> On 2003-06-17 at 11:32:51 [-0700], Ingo Weinhold wrote:
> > > 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?

That's the big question. :-)

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

I recently tried the SuSE Linux partitioning program. When creating a 
partition it first asks what type of partition to be created -- 
primary, extended or logical -- and then (or immediately, if there's 
only one option) pops up a dialog to set the parameters. IIRC, for 
primary/logical partition one chooses a FS type and can say whether or 
not to initialize the partition. I find that rather straight forward 
and think, that, even if our DriveSetup will end up totally different 
and better, it should be possible to implement it similarily using the 
DiskDevice API. That is, I think, being able to set the type of a 
partition without at the same time initializing it should be possible.

I believe, we can do that, if we 1) treat the types less second-class 
as we do now and 2) make the two fold nature of partition 
initialization more explicit. More precisely:

1) Currently the types are passed only one way, from the partitioning/
FS modules to the API user. They have no meaning in userland other than 
that the user can read them and, due to the standardization (<
DiskDeviceTypes.h>), that applications can find out, if the type is one 
they know. The types aren't passed back to the disk device manager for 
initialization. The problem, that one module can deal with more than 
one type, can easily be solved by simply forbidding it. One module -- 
one type. Since one kernel add-on can contain an arbitrary number of 
modules, that doesn't really hurt, because functions can be reused. 
E.g. the FAT file system could provide three (12/16/32?) modules, each 
of which could using the same hooks, save a few like mount and 
initialize maybe (which nevertheless can be stubs invoking a common 
worker function). What we gain is BPartition::Type() == 
BDiskSystem::PrettyName() and thus a way to specify the type on 
initialization.

2) Why not introduce a BPartition::SetType(), that tells the 
partitioning system to set the type of the partition? Or maybe rather 
add a boolean parameter to Initialize() indicating whether to only set 
the partition type or to also let the supplied disk system format its 
contents? That still doesn't solve the problem, that a partitioning 
system may not know a new FS type, but we can deal in a more user-
friendly way with it. A BDiskSystem method would return whether it 
knows the type or not, and, if it doesn't, whether it would 
nevertheless allow initialization with the respective disk system. That 
way the user can be told, that they either cannot set the partition 
type or must also initialize the partition. I think, it would make 
sense to supply a partition type to BPartition::CreateChild() as well.

How does that sound?

CU, Ingo