lkml.org 
[lkml]   [2001]   [Aug]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [ANNOUNCE] Gujin graphical bootloader 0.4
From
Date
"H. Peter Anvin" <hpa@zytor.com> writes:

> This is indeed a good structure, but this wide interface is a pain to
> keep stable, and having bootloaders call it directly is a genuinely
> bad idea. It will lock us into an interface, or cause major breakage,
> when we have to do necessary revving of this interface.
>
> Instead, the proper time to deal with this is at kernel link time.
> The PC-BIOS stuff should go in, say arch/i386/pcbios, and you then can
> have other platforms (say, for example, arch/i386/linuxbios) which has
> its own setup code. You then link a kernel image which has the
> appropriate code for the platform you're running on, and you're set.

Probably. My hope is that with linuxbios I can come up with a format
that is sufficient to be an internal interface. There is also another
major reason for looking at this. We don't have the same kind of
interface on any port. For example rdev only exists on x86. Making
the whole bootloader process a major pain everytime you swich a linux
hardware platform.

> You're now
> encoding a ton of assumptions about what the kernel needs in each and
> every bootloader, which is bound to cause a major headache not too
> long down the road. For example, the stuff you describe above may
> very well be obsolete in 2 years with HyperTransport, Infiniband and
> 3GIO on the very near horizon. Now you have to suffer dealing with
> lots and lots of compatibility logic to make things work, which may
> not be possible, or we're going to have frequent breakage.
>
> I do not believe this is a good idea. This kind of information
> belongs in the kernel image, although it should be abstracted out
> within the kernel tree.

>From your reaction I'm not explaining myself well. And since I'm
working with a work in progress that isn't too much of a suprise.

The basic rule is that nothing that can be queried from the hardware
directly should be passed to the kernel. However we do need to have
an interface to describe the hardware that we can't do a
PCI/ISAPNP/USB/etc bus scan to get. To a certain extent the
information is optional because sometimes we cannot get it. But if we
can it is good to have.

That is all I intend to pass to the linux kernel besides a command
line the unprobeable hardware details. If something becomes probeable
in the future that wasn't in the past, I'd spec it as optional to pass
that information.

For the kernel loaders I'd definentily have a standard probe routine
that would query the traditional BIOS, and then package the results in
the format I'm suggesting. Because of working around BUGS sometimes
you need extra information that gets lost in translation, so I'm not
100% certain that is the best way to go. However it is possible to
turn things on their heads and share the same code between multiple
operating systems at which point it makes real sense to move that code
into a bootloader. This is one of those questions worth looking very
closely at.

For the unprobeable hardware what I want to do is pass in what amounts
to a struct pci_device tree. But with struct pci_device generalized
to struct device as has been proposed for 2.5. A preseeded tree
shouldn't be to hard to check up on, to see if it is accurate.
Verifing that I can handle resources like interrupts, and structures
that are not trees is my current challenge, with this. Things like
interrupts tend to at least be DAGs. I think the interfaces will need
some small extensions to handle 3GIO, Hypertransport, and Infiniband,
and other bus technologies to come. Sort of like you need another RFC
when you encode another protocol on top of IP. Just something to
specify exactly how the encoding will work.

I'll fight this in a month or two when I start integrating this into
2.5 and have had a chance to start integrating this in. I'll see if I
can have this as a seperate of startup files in early 2.5 so that this
code can be tested seperately. But there is real virtue in putting
all of your software eggs in one basket so long as it is a very good
basket.

Eric

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 12:57    [W:0.049 / U:0.692 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site