Hi Eric,
I think you are on the right track with this. We want the best of both
worlds.
Maybe an easier track is to get code that will compile as part of
LinuxBIOS and as a kernel module. When I was testing the L2 cache code
I built it as a kernel module and just loaded it into a running Linux
kernel. No need for reboots unless the code crashes out the system. We
could do something similar with various linuxbios services. A LinuxBIOS
build would build the flash image and a module. Linux would boot and
then load the bios module. Both parts could share the same code to make
the services identical. This way we don't have to re-engineer insmod.
Regards,
Denis.
Eric Seppanen wrote:
>
> On Mon, Dec 11, 2000 at 03:53:26PM -0700, Ronald G Minnich wrote:
> >
> > it's easy to fix as soon as I can figure out the interface between linux
> > and linuxbios.
>
> After thinking about this for a couple of days (we were talking about
> software reset) I still don't understand what you meant when you wrote
> this.
>
> But it got me to thinking (and maybe this is what you were thinking)...
> there seems to be a lot of things that maybe people want to do in
> linuxbios, and maybe people want to do in the kernel, and sometimes may
> want accessible from both places, and it occurs to me that if you could do
> this, you could have the best of both worlds:
>
> The idea is: have linuxbios copied to ram before the kernel is started,
> then teach the linux kernel to recognize linuxbios as though it were a
> sort of kernel-module, and make the linuxbios namespace and functions
> available from within the kernel.
>
> Then, if you teach linuxbios how to fiddle with the CPU clock, you could
> later call the same functions from the kernel.
>
> ditto IRQ routing, chipset tweaking, ram settings, hardware-reset...
>
> Does anyone know the guts of kernel-module runtime linking to know if this
> is a possibility?
>
> Other comments?
>
> Eric
