Re: Disk Device API: Some semantical questions

On Fri, 11 Jul 2003 01:04:21 -0700 Tyler Dauwalder <tyler-cyCl/[email protected]
> wrote:
> On 2003-07-10 at 20:27:31 [-0700], Ingo Weinhold wrote:
> > On Thu, 10 Jul 2003 14:08:18 -0700 Tyler Dauwalder 
> > <tyler-cyCl/[email protected]
> > > wrote:
> > [...]
> > > > BTW, what kind of partitions does
> > > > BDiskDeviceRoster::VisitEachInitializablePartition() visit, 
> > > > i.e.
> > > > what
> > > > is an initializable partition? Something like the device is not
> > > > read-
> > > > only and there exists a disk system for which the partition's
> > > > CanInitialize() would return true? Sounds a bit complicated.
> > > 
> > > I think something more along the lines of "the device is not read
> > > -
> > > only
> > > and partition->Parent()->DiskSystem()->SupportsChildSystem() 
> > > returns
> > > true for some available disk system and there exists an available
> > > disk
> > > system such that
> > > system->SupportsParentSystem(partition->Parent()->DiskSystem())
> > > returns
> > > true", again pretending BPartition::DiskSystem() exists instead 
> > > of
> > > BPartition::GetDiskSystem(). I guess the question is how useful 
> > > it
> > > is.
> > > If we want to give a complete overview in DriveSetup of which
> > > partitions
> > > are initializable, we'll have to do something similar anyway. If 
> > > we
> > > want
> > > to make the user check on a partition by partition basis if a 
> > > given
> > > partition is initializable (i.e. by right-clicking and seeing if 
> > > an
> > > "initialize" item is avaliable or something similar), then the
> > > Visit...() function may not be all that necessary. I kind of like 
> > > the
> > > first ides better though.
> > 
> > I wonder whether we cross the line of what should be provided by 
> > the
> > API and what can be implemented in DriveSetup here. The method will 
> > be
> > relatively expensive if all these checks are done and DriveSetup 
> > will
> > have to implement the functionality to get all disk systems a 
> > partition
> > can be initialized with, anyway.
> 
> That's a good point. I would say we could probably do without the 
> "InitializablePartion" and "PartitionablePartition" versions. I think 
> the mounting related ones make sense, and the other three are 
> certainly 
> reasonable.

OK, then I'll remove the former ones.

> What is the "device" parameter to VisitEachDevice() for? Is it 
> intended 
> to actually be a BDiskDevice** output parameter, a la the partition 
> parameter for VisitEachPartition(), instead of BDiskDevice* as my 
> copy 
> is labeled?

No, it is a BDiskDevice* output parameter. You (can) supply a pointer 
to an uninitialized BDiskDevice and when the visitor requested to stop 
at a particular device, the supplied object is initialized to represent 
this disk device.

> For VisitEachPartition(), the "device" parameter allows you 
> to specify a single device on which to visit all partitions, IIRC, 
> but 
> that doesn't make much sense for VisitEachDevice().

The BDiskDevice* parameter passed to the partition visiting methods is 
an output parameter as well. Since a BPartition object can only exist, 
if it belongs to a BDiskDevice, there must also be a BDiskDevice, if we 
want to return a BPartition*. And that's the function of the device 
parameter; it is set to the device that contains the found partition.

If that is confusing, we can still change the visiting methods to just 
return a partition_id (all of them) instead of a bool and have no 
further parameters. Then the caller can get a device/partition object 
via Get{DiskDevice,Partition}WithID().

CU, Ingo