[openbeosstorage] Facing the End ;-)

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.

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

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

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

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

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


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

* 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


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

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.

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.

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

CU, Ingo

Other related posts: