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

[Tyler Dauwalder <tyler@xxxxxxxxxxxxx>]

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

Sounds very good.

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

I think I like the SetType() way better. Initialize(bool) would leave 
me feeling slightly uneasy that perhaps I got the boolean value 
incorrect when I only wanted to change the partition type.

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

Sounds good.

> I think, it would make
> sense to supply a partition type to BPartition::CreateChild() as well.

Sounds like a good idea also. :-)

-Tyler