Re: Facing the End ;-)

On 2003-01-21 at 16:29:59 [-0800], [email protected] wrote:
> 
> Hi,
> 
> 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. I need to play with it a bit more, 
then I will let you know what I find.  

> * 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.

> * 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.

> * 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. 

> Regaring the FS flags
> mentioned in my previous mail, I will add a `fs_flags' field to
> extended_partition_info, that will look the same as fs_info::flags. 
> (If
> also a free_blocks would be added, then one should have enough
> information for resizing of partitions.)

Sounds good.

> * 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?

> * Currently I'm not sure how changes of devices are detected. Any 
> idea,
> how one can find out, whether e.g. the CD has been changed, or the
> floppy?

No help here. :-(

> To sum it up, I think, basically the functionality of our low level 
> API
> is sufficient to implement the functionality of the C++ Device API.
> Only the item listed last needs a solution, but I believe, that's
> nothing the disc_scanner API should (or can) provide; there's 
> certainly
> some syscall()/ioctl() that supplies the needed information.
> 
> Anyway, here are some questions concerning the disk_scanner stuff:
> 
> * Shall there be a difference between the file_system_short_name field
> in the extended_partition_info structure and the fileSystem parameter
> of the initialize_volume() (or mount()) function? I originally 
> thought,
> that it might be better to have a long and a short name presentable to
> the user and an only internally used identifier. But maybe that 
> doesn't
> make much sense. The GUI add-on API has different getter functions for
> both. The same holds for the partition add-on.

I don't think I see any reason to differentiate between the two. 
Particularly if we clearly document the fact that the short name is 
used for initialize_volume() and friends, I don't see why it'd be a 
problem.

> * I think, it is a good idea, if get_nth_partition_info() could
> optionally return the identifier of the partition module (and if short
> name != identifier also of the FS), since currently it is not even
> possible to find out which GUI add-on belongs to the partitioning
> system used for a certain session.

Fair enough.

> * 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. :-)

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

> E.g. remove a couple of public setter methods or make them private.
> Partition has bunch of them, but I actually don't see why. The Tracker
> uses three (SetMountState(), SetMountedAt() and SetVolumeName()), but
> only to update an object when changes occured. I find it more logical
> to rather introduce an Update() method that retrieves and sets the
> information by itself.

Sounds reasonable.

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

> 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... ;-)

-Tyler