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.
> Currently I have a stable easy to use structure that isn't even linux
> specific with just a few more details on how to encode parameters to
> work out. The structure is the ELF format for static executables,
> with a specific implementation of how parameters will be passed to it
> from the bootloader, before the bootloader goes away. In particular
> how to specify things like onboard ISA devices so we don't even have
> to assume what is or is not present on a motherboard for those devices
> that don't support probing and there is a firmware interface for
> finding them. The interesting case there is not so much how to encode
> the device but instead on how to represent the location of devices,
> and the connections between devices.
>
> Being able to describe how an interrupt goes from a pci slot to an irq
> router to a legacy interrupt controller to a local apic and to the
> cpu, and simultanesly goes from the pci slot to an ioapic to a local
> apic to the cpu. And saying that pci slot is behind a PCIX<->pci
> bridge. Is an interesting question. Especially in data structures
> that have very few special cases. We are close in the kernel with
> struct resource, and struct pci_device but we haven't gone all of the
> way yet.
>
> So no I don't think it is right to blast someone for using the 32bit
> entry point, while at the same time I do agree that right now it is a
> very questionable things to do.
I haven't blasted anyone; I said it is a bad idea. 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.
-hpa
-- <hpa@transmeta.com> at work, <hpa@zytor.com> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt <amsp@zytor.com> - 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/