FreeLists / openbeosstorage / [openbeosstorage] Re: DiskDevice API v2.0

[Tyler Dauwalder <tyler@xxxxxxxxxxxxx>]

On 2003-04-03 at 22:32:37 [-0800], Ingo Weinhold wrote:
> 
> Tyler Dauwalder <tyler@xxxxxxxxxxxxx> wrote:
> > 
> > > > > That reminds me: How would you want to treat empty partition
> > > > > table
> > > > > slots
> > > > > in the API=3D3F In the previous one they were represented as
> > > > > partitions
> > > > > being
> > > > > marked `empty'. Instead Index() could return the actual index.
> > > > > I'm
> > > > > not
> > > > > sure though, if that would be confusing, since it could differ
> > > > > from
> > > > > the
> > > > > index of the object in the parent's list. Maybe a second 
> > > > > method
> > > > > (ActualIndex())=3D3F
> > > > 
> > > > Actually, I think I was intending only to return non-empty
> > > > partitions
> > > > in the C++ API, and then let the kernel level stuff do any magic
> > > > related to physical indexing (I believe this is how
> > > > PartitionMagic
> > > > does
> > > > it, actually). That seemed most appropriate for a user level 
> > > > type
> > > > API.
> > > > What do you think=3D3F
> > > 
> > > While I agree that most users won't care, e.g. for Linux the
> > > physical
> > > indexing is of some importance -- if our DriveSetup `magically'
> > > changes
> > > it, Linux might be rendered unbootable. Mmh, maybe we shouldn't
> > > care
> > > and assume that Linux users know what they are doing.
> > 
> > Well, I also figured we would do the right thing wrt indexing (it's
> > physical ordering matching partition table index ordering you're
> > referring to, right=3F), including reindexing if necessary.
> 
> Depends on what you consider the right thing. E.g. when deleting the
> first of two primary partitions on a disk, you have two choices, what
> to do with the primary PTS: 1) Move the descriptor of the remaining
> partition to the first slot, or 2) leave it where it is. If this 
> choice
> is not made available to the user, obviously the system has to make 
> the
> decision. But I believe, most of the users don't care, and those that
> do, rarely will face a situation in which automatic reindexing will
> have undesired effects, at least, if strategy 2) is applied if
> possible.

That's basically what I was thinking. 

> [...]
> > > > > 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=3D3F
> > > 
> > > 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. 

-Tyler