[openbeosstorage] Re: DiskDevice API v2.0

Tyler Dauwalder <tyler@xxxxxxxxxxxxx> wrote:
> 
> On 2003-04-03 at 22:32:37 [-0800], Ingo Weinhold wrote:
[...]
> > > > > > As a static list it is OK, I think, but the updating on
> > > > > > notification
> > > > > > could
> > > > > > work better. I don't even think the problem is just the
> > > > > > implementation of
> > > > > > the class itself, but also the way the notifications work.
> > > > > > 
> > > > > > If you re-partition a disk, then the registrar recognizes 
> > > > > > that
> > > > > > some
> > > > > > partitions have been added and some removed and it sends a
> > > > > > notification
> > > > > > message per recognized change. The BDiskDeviceList receives 
> > > > > > the
> > > > > > first
> > > > > > message of the incoming series of notifications, updates 
> > > > > > the
> > > > > > concerned
> > > > > > BDiskDevice and calls the hook method. Since updating the
> > > > > > device
> > > > > > really
> > > > > > brings the object up to date, it is already up to date, 
> > > > > > when
> > > > > > the
> > > > > > second
> > > > > > notification arrives. This is, what I don't like.
> > > > > 
> > > > > Oh, I see. I thought the updates contained the necessary info 
> > > > > for
> > > > > updating manually, I guess. In this case then, only one hook 
> > > > > is
> > > > > really
> > > > > needed to know when to update then, correct=3D3D3F
> > > > 
> > > > Then the notification messages with the (more) precise event
> > > > descriptions make little sense. A solution would be, if the
> > > > internal
> > > > update of a BDiskDevice/BSession/BPartition had invoked call 
> > > > backs
> > > > corresponding to what had actually happened. But that wasn't 
> > > > how
> > > > the
> > > > framework was designed, so it would have been difficult to
> > > > implement
> > > > it
> > > > this way.
> > > 
> > > Well, unless the precise event messages also contain the 
> > > necessary
> > > info
> > > to update a given set of objects without consulting anyone else, 
> > > I'm
> > > not sure I see the usefulness in them over a general "things have
> > > changed" event.
> > 
> > I believe, a `partition added' is more useful than a `device 
> > changed'
> > event, even if the complete partition info isn't included in the
> > message (but only its ID). However, I think, it should be possible 
> > to
> > improve the implementation, anyway.
> 
> Okay, then let's try to include everything needed to manually update 
> a 
> BDiskDevice and it's children in response to a given notification 
> without having to ask the kernel to do it for us. 

I was first sceptical, because the amount of data to be sent, when the 
hierarchy changes, might be (or rather: was) relatively great. But 
since the granularity of the actions performed is rather fine now, this 
shouldn't be a problem anymore. It becomes rather important, that all 
notification messages are actually received, but by moving the message 
delivery for notifications of all kind from the kernel into the 
registrar, this should be rather safe to assume. As a fallback for very 
rare situations the complete device can be updated (a change counter as 
already implemented can be employed to detect skipped notifications).

CU, Ingo

Other related posts: