"Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx> wrote: > "Ingo Weinhold" <bonefish@xxxxxxxxxxxxxxx> wrote: > > "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx> 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