ollie lho <[EMAIL PROTECTED]> writes:
> 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 ??
If you can code it in assembly it can be coded in another form. The
structure of the code generation algorithm (and possible the language
itself) would need to be different from a classic compiler.
And if it runs out of resources the code would fail to compile.
In practice this would mean all of the code would need to be compiled
at once, and inlining would need to be rampant. Because you only have
64 bytes of memory. The fundamental technique would be trading code
size and hard coded tables for very little memory usage.
> > 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 ??
I have to fit in a rom. The data size I don't worry about but the
text size I do. Compressing the code code would help etc.
While we have to deal with 256K Roms size will always be tight. And
while the task is simple enough we don't need to worry to much, a
little worry now while we aren't bad should keep us from having
problems. And make room for more interesting functionality like
bootloaders. And also make the whole process faster given that rom
chips are very slow.
> > 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;
Sounds roughly right. After thinking about it some more I actually
thinkg we can go there, without a radical step like freebios2. The
only practical objection I can think of is that it would mess up some
hardcodes. Which is actually a good thing as it puts pressure on us
to do things dynamically.
As a small step in that direction I propose having drivers for pci
devices, that initialize devices. Semantically equivalent to the
loop.
while(dev = pci_find_device(vendor, device)) {
intitialize(dev);
}
Except packaged as something like.
struct pci_id ids[] = {
{ vendor, device },
{ vendor, device },
{ vendor, device },
...
{ 0, 0 },
}
struct driver {
struct pci_id ids;
void (*initialize)(struct pci_dev *dev);
...
} pci_driver = {
pci_ids,
initialize,
...
};
We will need to have helper libraries under the covers building up the
data for tables, etc. But I believe this can be the primary interface
to most of the device initialization needed in LinuxBIOS.
Eventually we can enhance it with dependecy information on what needs
to happen first. But given how many surprises I have seen from
hardware slowly evolving the interface looks good.
Ollie I think with just a little care this should work for your
northbridge init problem. The very nice thing here is that this
should be straight forward to implement, comprehensible, and work
for a great number of cases.
So at this point, do you want to write it or should I?
Unless you can find the flaw in my beautiful idea :)
> > 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.
For this I only care if I have a hard drive. What I'm personally
after is a quick fix so I don't need to provide the capability to have
multiple images on a hard drive, or implement partition support, etc.
I personally think it is unnecessary bloat that gets in the way of the
focusing on a small number of interfaces that can be made reliable and
general purpose.
Eric
