On Fri, 2002-06-28 at 12:24, Eric W. Biederman wrote:
> 
> What I would rather see long term is a C or C-like language with a
> compiler that just uses registers.  
> 

A compiler without register spill ?? I am not CS background, but is it
possible form programming language (theory) point of view ??

> And I also want to look into what it would take to compress the rest
> of LinuxBIOS besides the memory setup code.  Though maybe I should
> just become a terror to all of the strings and printfs present, and
> see if there is any code I can remove.
> 

Why do you want to do that ?? The memory space critical part is actually
the memory setup code. Once you have memory up, why do you worry about
code size at all ??

> 
> For me I've go some ideas, but unless we fork off a development
> and stable branch, I'm going to be go there as gradually as I can.
> 

Is is what I intended originally. Probably we need to start a freebios2
somewhere in the future.

> Probably something like the nsuperio architecture, but looked into
> the a device tree, like we have for pci.
> 

What I was imaging is something like the current Linux PCI device driver
interface. The driver provides some static device probe/identify 
structure, the main code uses the struct to "install" the driver (in
OO terms, constructor of the device object). This can not only be used
for PCI device, for instance, with properly modified cpuid routines,
we can also have some "CPU driver" too.

/* ??? warnning, mixture of C and C++ */
class cpu_driver: generic_device {
public:
        probe: cpuid();
private:
        /* our own member function */
        cache_on: intel_cache_on();
        mtrr: p6_mtrr();
} intel_p6;

> Anyway, ollie what were the issues with grub.  Just skimming the code
> it doesn't look terribly hideous.  Maybe the devil is in the details.
> It looks like a port of grub could be done, without a hideous amount
> of effort. 
> 

I forgot most of the detail. But here are few points:

        1. As Linus, I really hate the #ifdef stuff, and GRUB has more
           than anyone can bear.
        2. Due to #1, this means that GRUB was not properly abstracted.
        3. You will find it out as you look it deeper. As you said in
           the follow-up mail.

> Grub certainly isn't my favorite bootloader, but having a cheap menu
> to select between different kernels on the disk would be nice.
> 

Once we have the infrastructure, a boot menu would be very easy
to implement.

Ollie


Reply via email to