[openbeosstorage] Re: Partition detection in the boot loader & kernel module discussion
- From: "Ingo Weinhold" <bonefish@xxxxxxxxxxxxxxx>
- To: openbeosstorage@xxxxxxxxxxxxx
- Date: Sat, 24 May 2003 19:47:51 +0200 CEST
"Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx> wrote:
> "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.
Ah, OK.
> > > 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.
Yes, I think that should be possible. I'll have that in mind when
continuing my draft.
> > 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 ;-)
And it certainly runs only under Windows. Or with a lot of luck also on
a Mac. Hey wait, I even have an old Mac.
> 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 :-)
On the other hand it is human readable and there exists a standard way
of copying. :-P
But anyway, when I introduced it in the Intel module I was under the
impression, that those strings were exactly what you meant making the
parameters (at least for FSs) driver settings compatible. As it turned
out later, this was a misunderstanding. It shouldn't be a big problem
to turn that into some flat structure, though.
CU, Ingo
Other related posts:
