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

["Ingo Weinhold" <bonefish@xxxxxxxxxxxxxxx>]

"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