FreeLists / openbeosstorage / [openbeosstorage] Partition detection in the boot loader & kernel module discussion

["Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>]

Hi there,

I must admit that I was a) lazy, and b) wanted the partitioning scheme 
detection a bit faster for the boot loader (doesn't have to be, though, 
since I don't use any caching for the boot block - maybe OpenFirmware 
does (or the drive), though).

That's why I used the following API:
The partitioning modules only export one function (they are read-only):
        status_t scan_for_partitions(list *partitionList, int deviceFD);

On the other side, the boot loader exports:
        add_partition(list *partitionList, Partition *partition);

It's a very simple API as you can see, but it's also very powerful - 
the Partition objects can contain private data for the partitioning 
scheme used.
Currently, though, they are very simple objects that do exactly the 
minimum needed.

The advantages of this approach is that it is very simple and only 
requires a minimum API. The downside is that we would need to write 
extra (but very small and simple) partitioning modules for the boot 
loader (which are statically linked, though), and that it's not very 
nice for dynamic environments - but of course, add_partition() could 
check if it has to update an existing partition or not.
I think that the current kernel module API could be enhanced and 
simplified, though. The partitioning module should be able to keep some 
data between calls to partition_identify() and 
get_nth_partition_info(). It currently only has direct access to the 
first block which seems to be a bit static.
For example, the Amiga RDB module had to search the first 16 blocks of 
a disk in partition_identify(), and if I am not mistaken, again in all 
subsequent calls to get_nth_partition_info(). And that's certainly not 
what we want.

I am not yet sure, but we might be able to have a cache layer on top of 
access to /dev entries in OpenBeOS (there is none in BeOS, though) - 
this would make things easier, but in any way, we could change the API 
at a later point to address those issues.

I know that I triggered the addition of the "block" field in the first 
place, but I am not sure if it's appropriate anymore - we could check 
how fast the drive's cache is if VFS access to the disk is uncached.

So, if we neglect the "block" parameter for a while, I would propose an 
API like this:

bool identify_partition(int fd, const struct session_info *session, 
void **_cookie);
status_t get_nth_partition_info(int fd, const struct session_info *
session, 
        void *cookie, int32 index, struct extended_partition_info *
partitionInfo);

Of course, we could also still have the block parameter - but I would 
prefer a cleaner solution; the cleanest would be a cache layer on top 
of the deviceFD, of course.
I'll look into that after VM2 is integrated and begin work on the file 
system cache.

Adios...
   Axel.