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

["Ingo Weinhold" <bonefish@xxxxxxxxxxxxxxx>]

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.

[...]
> > > > > > Partition.h
> > > > > > -----------
[...]
> > > > > > (as is PartitionWithID*(), BTW).
> > > > >
> > > > > This is a leftover from the first draft, and actually I'm not
> > > > > sure I
> > > > > see the point of it when there's
> > > > > BDiskDeviceRoster::GetPartitionWithID().
> > > > 
> > > > Mmh, maybe the approach isn't intuitive enough. The fundamental
> > > > idea
> > > > is,
> > > > that the atomic piece of information one can get is a 
> > > > BDiskDevice
> > > > object
> > > > with a complete partition hierarchy. The BDiskDeviceRoster 
> > > > `checks
> > > > out'
> > > > such an object and returns a pointer to the contained 
> > > > BPartition
> > > > with
> > > > the
> > > > respective ID. This is indeed heavy weight.
> > > > 
> > > > The BDiskDevice method on the other hand searches the 
> > > > BPartition
> > > > with
> > > > the
> > > > ID in question in the already present hierarchy. Compared with 
> > > > the
> > > > former
> > > > one it is light weight.
> > > 
> > > Okay, I see. That does make sense once you know how it's intended 
> > > to
> > > work.
> > 
> > If you have other ideas, don't hesitate to tell -- it's not like 
> > I'm
> > particularly fond of this approach.
> 
> I'm just not sure how useful the lightweight version really is. I can 
> see having the general version, certainly, but the multiple versions 
> seems a little like overkill.

OK, just remove it.

[...]
> > > > 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.

CU, Ingo