[openbeosstorage] Re: Partition detection in the boot loader & kernel module discussion

"Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx> wrote:

> 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 don't get the last part. I thought, these minimal modules would be 
used by the boot loader only. In the boot phase everything should be 
rather static, shouldn't it?

> I think that the current kernel module API could be enhanced and 
> simplified, though.

Definitely.

> The partitioning module should be able to keep some 
> data between calls to partition_identify() and 
> get_nth_partition_info().

Yep, I was already planning support for that.

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

Sure, and it might be even worse with getting the session infos for a 
CDs.

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

That could indeed be a good idea (at least for disk-like devices).

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

The tests with the current DiskDevice API implementation showed that at 
least the API was rather slow. Though that means little, since the 
userland disk_scanner API function allowed iteration by session and 
partition index only and thus introduced much overhead for the user.

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

Well, it shouldn't look like that, if we want to consequently introduce 
the unification of sessions and partitions into the kernel 
(disk_device_manager) and kernel module handling.

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

That would be great!

OK, I see, the time is more than ripe for me to resume my work on my 
proposal for the implementation of kernelland part of the disk device 
stuff. I'll do that as soon as I've dealt with my tax declarations (*
shudder*).

CU, Ingo

Other related posts: