[openbeosstorage] Re: Partition detection in the boot loader &kernel module discussion
- From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
- To: openbeosstorage@xxxxxxxxxxxxx
- Date: Sat, 24 May 2003 19:21:42 +0200 CEST
"Ingo Weinhold" <bonefish@xxxxxxxxxxxxxxx> wrote:
> "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx> wrote:
> > 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?
Exactly, it was only meant as an argument against using that API in the
real kernel.
> > 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.
True, yes.
But I still think it would be nice to have one API and one set of
partitioning modules that could be used by both, the kernel and the
boot loader.
Of course, the boot loader would only need read-only capabilities which
could be ensured by having a BOOT_LOADER define.
> 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*).
Yeah, I need to do the same thing ASAP - I always hated that. There is
now even the possibility to make it online, but they have just made a
(very buggy) program that has the same forms as you would need to fill
in on paper. Almost unusable, although you don't have to enter your
name that often ;-)
Anyway, I have another feeling against the current kernel API: the
parameter map. Does this really have to be a string? If every
partitioning system has to come up with it's own parsing language etc.
why not just have a structure that holds all data? That would reduce
the complexity that had to be copied to every module considerably.
Also, parsing a string often calls for bugs :-)
Adios...
Axel.
Other related posts:
