Re: DiskDevice API v2.1

Tyler Dauwalder <tyler-cyCl/[email protected]> wrote:
> 
> > > > If
> > > > that
> > > > would require absolute blocks, we should go back to the drawing
> > > > board
> > > > :)
> > > 
> > > If UDF does, I would vote for omitting support for it out of 
> > > principle
> > > (if necessary, locking Tyler into some basement without 
> > > computers).
> > > ;-)
> > 
> > :-P That's a really bad idea all around. :-)
> > 
> > Seriously, with no UDF support, you have no DVD support. And 
> > iso9660 
> > is
> > no better, and we sure aren't dropping CD support. How about
> > BDiskSystem::UsesAbsoluteAddressing()=3F
> 
> Let me clarify this a bit (I was in a bit of a hurry last night... 
> :-/). We could support generic moving for any disk system that didn't 
> require absolute addressing. For those that do, they can either 
> support 
> moving themselves, or just be immobile (which, as Axel pointed out 
> earlier, won't matter in most cases anyway since they'll usually be 
> on 
> optical media anyway).

Agreed.

> > > > > > class BDiskSystem {
> > > > > > public:
> > > > > >     bool SupportsParentSystem(const char *system) const;
> > > > > >         // True in most cases. NULL =3D3D3D=3D3D3D raw device.
> > > > > >     bool SupportsChildSystem(const char *system) const;
> > > > > >         // False for most file systems, true for most
> > > > > >         partitioning
> > > > > >         // systems.
> > > > > >
> > > > > >     bool IsPartitioningSystem() const;
> > > > > >     bool IsFileSystem() const;
> > > > > > };
> > > > > As said above, I would make them virtual. Moreover, the 
> > > > > Supports*
> > > > > System()
> > > > > should also have a BPartition* parameter. Otherwise 
> > > > > partitioning
> > > > > systems
> > > > > that allow only a limited number of levels can't give an
> > > > > authoritative
> > > > > answer here. The BPartition* parameter could optionally be 
> > > > > NULL 
> > > > > to
> > > > > ask
> > > > > whether it is supported in general.
> > > > 
> > > > I think there should be read-only set of classes, and an 
> > > > additional
> > > > add
> > > > -on based set to actually do any changes. This will be only 
> > > > rarely
> > > > used, so it probably doesn't make much sense to clobber the 
> > > > general
> > > > API
> > > > with it - so I like something BDiskSystem (as a virtual (and
> > > > abstract)
> > > > base class), but it should contain everything, and not only the
> > > > check
> > > > operations.
> > > > Thoughts=3D3D3F
> > > 
> > > You mean that e.g. BPartition::Move() would be ommitted in favor 
> > > of 
> > > a
> > > BDiskSystem::Move(BPartition*,...)=3D3F
> > > Mmh, that doesn't sound very convenient.
> > 
> > No, I don't think I like that either.
> 
> And to clarify a little here, having immutable classes that are 
> updated 
> via a separate interface makes it more difficult to batch complex 
> operations on partitions that don't exist yet (i.e. creating and 
> initializing a bunch of new, even nested partitions). I don't really 
> feel like the general API is being clobbered here, just further 
> augmented.  

That's my opinion, too.

CU, Ingo