[openbeosstorage] Re: My Usual Confusion
- From: "Ingo Weinhold" <bonefish@xxxxxxxxxxxxxxx>
- To: openbeosstorage@xxxxxxxxxxxxx
- Date: Wed, 18 Jun 2003 02:41:20 +0200 CEST
On Wed, 18 Jun 2003 00:10:46 +0200 CEST "Axel Dörfler" <axeld@pinc-
software.de> wrote:
> "Ingo Weinhold" <bonefish@xxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxx> 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
Other related posts:
