Re: Disk Device API: Some semantical questions

On 2003-07-13 at 11:03:47 [-0700], Ingo Weinhold wrote:
> On Sat, 12 Jul 2003 12:44:55 -0700 Tyler Dauwalder 
> <tyler-cyCl/[email protected]
> > wrote:
> > On 2003-07-11 at 11:42:47 [-0700], Ingo Weinhold wrote:
> [...]
> > > > 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().
> > 
> > The only confusing part is that one is * and one is a **; that's 
> > what
> > threw me off originally. Wouldn't using the partition_id be a bit
> > more
> > expensive, since you'd have to look up the appropriate partition
> > again?
> > Or are you hashing the ids?
> 
> Yes, it would be more expensive. The device data had to be refetched
> from the kernel.

Okay, let's definitely stick with the original method then.

> 
> > Regardless, I think the way it's set up
> > currently is fine as long as it's properly documented, which it will
> > be. :-)
> 
> Which it already is. :-) The methods are virtually unchanged since the
> first iteration of the Disk Device API and so are their comments. Some
> methods still have the old comments, although their signature and/or
> their semantics have changed, though. I will document things properly,
> when the API is more stable... 

Damn, you're right. I forgot about the .cpp files. My bad. :-)

-Tyler