[openbeosstorage] Re: Facing the End ;-)

On Thu, 23 Jan 2003, Tyler Dauwalder wrote:

> On 2003-01-21 at 16:29:59 [-0800], openbeosstorage@xxxxxxxxxxxxx wrote:
>
> > for Tyler seems still to be busy with the CD session module, I wrote
> > down a little list of what I encountered re-reading DeviceMap.h.
>
> Well, that and life. :-) I think the session module is working now, but
> I'm running into partition problems.

Oh, hopefully nothing that my partition module is responsible for. ;-)

> I need to play with it a bit more,
> then I will let you know what I find.

Awaiting your flames...

> > * Quite at the beginning of the file one finds a enumeration of
> > P_UNKNOWN, P_UNREADABLE, P_ADD_ON and P_AUDIO. Though the `P_' sounds
> > a
> > bit like `partition', I think, these are session types
> > (Session::type).
> > P_AUDIO is clear and P_ADD_ON probably means, that there's a partition
> > add-on recognizing the session contents. I'm not sure, where the
> > difference between the other two is. Maybe P_UNKNOWN is just the value
> > for `uninitialized'. Then P_UNREADABLE stands for a session for that
> > no
> > partition add-on exists and that isn't audio.
>
> Sounds like a reasonable guess to me. For CDs at least, one can
> determine from the table of contents if the session contains audio or
> data tracks.

Yep. BTW, the session_info::flags is already capable of representing that
information: Data sessions have the B_DATA_SESSION flag set, audio session
have not. We could also reserve some more bits to be filtered by a type
mask, but I don't know, whether that would be needed in the foreseeable
future (Be used a bool BTW).

> > * In DeviceMapGlue.h we find the structure drive_setup_partition_flags
> > containing two flags, can_partition and can_repartition. Probably
> > partition add-on properties. There is a
> > Device::SetPartitioningFlags(),
> > but no method to get the values. No need to say, that the API doesn't
> > even support partitioning. Moreover I'm not sure what meaning
> > `can_repartition' has. Whether the partition add-on can re-partition
> > an
> > already partitioned device? That doesn't make much sense in my
> > opinion.
> > But I somehow doubt, that this is about moving and resizing
> > partitions.
> > Something we may want to consider, BTW.
> > Resizing is certainly something the FS must support in the first
> > place,
> > but it's certainly desirable to have support for this in the
> > disk_scanner module, too. I think, it could basically be transparent
> > for the API. That is, the GUI partition add-on would offer resizing/
> > moving of partitions as an option and set the parameters passed to the
> > kernel module accordingly. The kernel module would need some support
> > functions to tell the file systems on the concerned partitions to
> > adjust accordingly. I imagine a function that gets a list/array of
> > change requests, each one specifying old and new positions and sizes
> > of
> > partition contents. If possible, i.e. if all concerned FSs support the
> > requested operations, the requests are carried out, otherwise
> > rejected.
> > Then the partition module adjusts the partition tables and is done.
> > It would certainly be nice, if the GUI add-on could retrieve more
> > information about the FSs residing on the partitions of the session to
> > be resized, so that it could avoid presenting the user an option that
> > is not feasible. It would probably be sufficient, if a fs_info could
> > be
> > retieved for the FSs.
>
> I would *love* to see something like that supported at the OS level.
> Sounds a bit like R2 to me.

If there'll be resizing support in the file system R1 API, then I wouldn't
stand back regarding the partitioning support. :-P It shouldn't be that
complex (basically the one additional function I mentioned).

> > * Regarding flags for partitioning (that is those mentioned above): I
> > think, the GUI add-ons should return those, not the kernel module. As
> > I
> > tend to find it a good idea to make a respective GUI add-on a
> > requirement for partitioning, it appears to me, that then the GUI add-
> > on can tell, what extactly is supported.
>
> Hmmmm, wouldn't this bind you to using the GUI to perform a repartition
> or resizing? Say you have 200 computers, all with identical
> partitioning schemes, and you want to resize/repartition them all to
> new sizes, but would rather write a console app to do such a task than
> manually do it via the GUI on each one of them.

I understand the concern. The main problem is, that the partitioning
parameters depend heavily on the specific partitioning system, so that we
can't provide much generic support. What we can do easily and what should
help in the situation described above, is a to add not only a
Session::Partition() method, but also a
Session::GetPartitioningParameters(). Then the (not longer) console app
would invoke the latter one once -- the GUI pops up and lets the user edit
the parameters -- and pass the parameters retrieved that way to
Session::Partition() (a second version with parameters) on all computers.

> > * Do I overlook something, or am I right, saying that the BBitmaps
> > (largeIcon, miniIcon) in Device are not needed? A GetIcon() in
> > Partition would make some sense though.
>
> Perhaps the same icon is used for all partitions on a given device? Why
> not keep something like Device::GetIcon(), then add a virtual
> Partition::GetIcon() that can optionally provide a custom icon?

Of course you're right, there's one icon for all partition on a device.
The B_GET_ICON ioctl() can certainly be called on the partition devices,
but it finally arrives at the `raw' device driver. Nevertheless I think,
it is a good idea to only have a Partition::GetIcon(). In case, at some
time we have per partition icons, the implementation could be changed
transparently for the applications using that API. The reason why, I find
a Device::GetIcon() confusing is, that a device exists as an entity, but
it is never presented to the user; only partitions are.

[...]
> > * I still dislike the partition_code field in the
> > extended_partition_info structure, since it is partitioning system
> > specific, and therefore IMHO should not be in a generic structure. The
> > only reason why it's still there, is that I found it in the
> > partition_data structure used for the DriveSetup add-ons. What about a
> > little voting. :-P
>
> Tyler: Make it 32-bits and call it a day. :-)

OK, since I doubt, that I could convince Axel, I'll do that. :-)

> > Finally some words on the further proceeding. Since the disk_scanner
> > API seems to be sufficiently complete, I think, we can start with the
> > C
> > ++ API. Here some thoughts:
> >
> > I believe, it is a good idea to break source compatibility, even if it
> > is only to replace TypedList by BObjectList and move the classes into
> > an appropriate namespace (BPrivate:: or B* -- I prefer the latter
> > one)... and maybe rename Device to something less general, e.g. BDisk.
> > But actually I would even change some more things...
>
> I say, if we break compatibility, we go all out and fix the static,
> messy API as well.

That might be hairier than one might think at a first look. Perhaps we
should stick rather close to what Be did and rethink the API for R2.
Considering how long it already took us to come to this point (admittedly
I wasn't too busy with the matter and, I think, you weren't either ;-),
this is probably the fastest way. Designing an API from the scratch (and
taking care that it is done well) can be very time-consuming.

> > To tell the truth, I somehow dislike the whole API. It is too static.
> > Er, actually it simply is static. :-P If one takes a look at the
> > BVolume/BVolumeRoster classes, that's more like it should work: One
> > can traverse the current list and get notifications when something has
> > changed.
>
> I agree. It feels very unfinished and thrown together, which I imagine
> it probably was. I would much prefer to see it done properly.

So do I. My only concern is time. If I was outvoted -- or rather say, if
the majority opinion is to do it proporly right now -- I'll happily put my
heart and soul in it. :-)

Just as an outline of what I imagine should be done: First of all, we'd
need notification support in the kernel for events like media changes,
device partitioning and partition initialization. Furthermore I would
bundle all necessary activity in the registrar, and introduce a roster
class in the API to provide access to the device list and request
notifications.

The activities are, BTW, listening to all relevant events -- besides to
the ones listed above also to mount/unmount events and those concerning
the mount points (as the Tracker's AutoMounter does) -- and, of course,
scanning devices using the disk_scanner to find sessions and partitions;
simply whatever is needed to maintain a up to date list of devices. And
obviously the registrar has to send the notification messages to the
interest applications.

I haven't any more concrete ideas for the actual API. E.g. how much
information a BDevice/BSession/BPartition object would contain -- only a
handle used for communication with the registrar (the getter methods would
retrieve the information `live') or the/some actual data. One would also
have to think about efficient iteration.

> > Anyway, unless there are general objections, e.g. concerning the idea
> > of dropping source compatibility, I will come up with an API proposal
> > (headers and some documentation), that will be relatively close to the
> > current one. Don't expect anything before the weekend though. Enough
> > time for bashing. ;-)
>
> My only concern is wrt to the OpenTracker changes that would have to be
> made. And personally, I'm okay with doing the changes; I think it's
> worth it just to do the API right the first time. I'm just wondering
> what that OpenTracker guy will have to say to the idea... ;-)

That would be interesting indeed. :-P

BTW, I also looked through the Tracker sources and it seems, that the
changes would be quite local: Basically only the AutoMounter would be
concerned and the MountMenu (a bit). The question of how (if at all) a
common source tree for the different BeOS revival projects (and the
original BeOS, of course) can be maintained will come up earlier or later
anyway. Supposing that OBOS will be the most BeOS source compatible of the
projects, I think `someone' is looking forward to having a lot of fun. ;-)

What we can probably also do, is to implement the needed parts of the old
API as a (source) compatibility layer...

CU, Ingo

Other related posts: