Re: My Usual Confusion

On Wed, 18 Jun 2003 00:10:46 +0200 CEST "Axel Dörfler" <axeld@pinc-
software.de> wrote:
> "Ingo Weinhold" <bonefish-CFLBMwTPW48UNGrzBIF7/[email protected]> wrote:
> > 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.
> 
> That sounds like another good reason to move file systems to the 
> module 
> API.

Yep, modules are definately a cool thing.

On Wed, 18 Jun 2003 00:08:22 +0200 CEST "Axel Dörfler" <axeld@pinc-
software.de> wrote:
> Tyler Dauwalder <tyler-cyCl/[email protected]> 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?
> 
> Since those problems are probably limited to only one file system 
> (FAT), can't we just make an ugly special case for it? It would be 
> nice 
> if that could be done in the file system itself, since that one is 
> the 
> culprit here.

The three modules solution mentioned above should do, I guess. And I 
suspect, you're right, that FAT will probably be the only file system 
with such weirdness.

CU, Ingo