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

"Axel Dörfler" <[email protected]> wrote:
> "Ingo Weinhold" <bonefish-CFLBMwTPW48UNGrzBIF7/[email protected]> wrote:
> > "Axel Dörfler" <[email protected]> wrote:
> > > 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.
> 
> That would be very nice, thanks! I will then update the boot loader 
> as 
> required, and turn the Amiga RDB module into a real kernel module :-)

Cool!

> > > > 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.
> 
> Hehe, it doesn't pay off :-)

Damn! :-)

> But, how old is your Mac? Still 68k & NuBus? Or already PCI and 
> PowerPC? :-))

It's not *that* old. It is the machine with which I entered the BeOS 
user community, a PPC 604e 240 MHz.

> > > 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.
> 
> Indeed, as an alternative, we could use a real driver_settings 
> structure for that, if you prefer - I just want to have only one 
> location to fix for parsing strings :-)

Yes, I thought about that, too. We will see...

CU, Ingo