Followup to: <m1n157rrpk.fsf@frodo.biederman.org>
By author: ebiederm@xmission.com (Eric W. Biederman)
In newsgroup: linux.dev.kernel
>
> There are good reasons to use the kernel 32 bit entry point. In
> particular I routinely run linux on systems with exactly 10 16bit
> instructions. On one of them I don't even have normal memory between
> 640KB and 1MB. The only real parameter the kernel needs from the BIOS
> is memory size, and I could probably steel code from memtest86 so it
> wouldn't even need that.
>
> However I do understand the instabilities, and the deficiets of the
> current 32bit entry point, and why having a standard 16bit entry point
> is a good thing. Which is why in 2.5 (if it ever starts) I intend to
> do the work required so we can have a standard cross platform native
> mode entry point to the kernel.
>
> To keep linux portable we should never assume that on a given platform
> there is a specific kind of BIOS. Alpha-linux at least is nasty
> because of this. x86 linux is very nice because all you need to do on
> platforms that don't do support the classic BIOS interface is to drop
> the 16bit header. That is definentily a structure worth keeping.
>
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/
This archive was generated by hypermail 2b29 : Wed Aug 15 2001 - 21:00:37 EST