Go to the FreeLists Home Page Home Signup Help Login
 



[openbeosstorage] || [Date Prev] [04-2003 Date Index] [Date Next] || [Thread Prev] [04-2003 Thread Index] [Thread Next]

[openbeosstorage] Re: DiskDevice API 2.2 remarks

  • From: "Ingo Weinhold" <bonefish@xxxxxxxxxxxxxxx>
  • To: openbeosstorage@xxxxxxxxxxxxx
  • Date: Tue, 08 Apr 2003 23:14:02 +0200 CEST
Tyler Dauwalder <tyler@xxxxxxxxxxxxx> wrote:
> On 2003-04-08 at 12:01:20 [-0700], Ingo Weinhold wrote:
> > Tyler Dauwalder <tyler@xxxxxxxxxxxxx> wrote:
> > [...]
> > > > > BDiskDisk:
> > > > > ---------
> > > > > 
> > > > > * What meaning has the `checkOnly' flag of 
> > > > > SupportsRepairing()=3F
> > > > > Same
> > > > > in
> > > > > BPartition::[Can]Repair().
> > > 
> > > Well, I was thinking of offering the ability to make read-only 
> > > repair
> > > runs, i.e. verification runs. I'm not sure that's really 
> > > necessary
> > > though.
> > 
> > Ah, OK. Doesn't harm at least. BTW, the idea is to send encountered
> > errors via notifications? I hope that doesn't have impact on
> > performance. 
> 
> Yes, but only to the provided progressMessenger, not through the 
> watching system.

So, other notification subscribers could not get these data? IIRC, I 
already proposed to add a B_DEVICE_JOB_PROGRESS notification "event" 
field value and a respective event mask flag (can't find the mail -- 
maybe I was just dreaming). A B_DEVICE_JOB_DETAILED_PROGRESS plus event 
mask flag could be added, too. Moreover I start to feel, that a 
BDiskDeviceRoster::StartWatching(BDiskDeviceJob*,...) version might 
make sense. What do you think?

[...]
> > > > > It may be better to introduce
> > > > > [Can]Delete() instead (or additionally).
> > > 
> > > Well, I had those in there, but I felt they fell under the same
> > > argument as the one use for eliminating
> > > BPartitionableSpace::CreatePartition(), i.e. the BPartition is
> > > suddenly
> > > going to disappear or at least be invalid.
> > 
> > Although at least the name Delete() should be hint enough for the 
> > user
> > to not be too surprised. ;-) However, since one can only delete 
> > child
> > partitions (not devices) DeleteChild() is probably better. Maybe we
> > should add an additional DeleteChild(BPartition *child) version.
> 
> DeleteChild(child->Index()) ?

Okay, okay, you win. :-)

[...]

CU, Ingo






[ Home | Signup | Help | Login | Archives | Lists ]

All trademarks and copyrights within the FreeLists archives are owned by their respective owners.
Everything else ©2007 Avenir Technologies, LLC.