> > I agree writing the code to understand the table may be a significant
> > issue. On the other hand I still think it is worth a look, being
> > able to unify option parsing for multiple platforms is not a small
> > gain, nor is getting out from short sighted vendor half standards.
>
> Well, you certainly have a point where stupid vendors and BIOS nonsense
> are concerned. However, if we ignore LinuxBIOS for a moment, each
> platform already has a set of configuration parameter passing conventions
> imposed by the firmware. So we need to be able to handle this anyway, and
> most of the information is highly platform-specific.
Well, I never intended for my UBE stuff to handle probeable
information, and after thinking about it. It does seem reasonable to
say that a table in a firmware rom (or generated by one) is as
probeable as a table in a device rom.
> LinuxBIOS is a special case, because you have your own firmware. But
> what you're suggesting is basically yet another parameter format, which
> needs to incorporate and possibly unify much of the information
> contained in all those platform-specific formats. I'm not sure it's worth
> the effort.
Well I half agree. I think where I'm going to go is to propose some
new BIOS tables, as there are some truly broken platforms out there.
In particular on alpha you can't even build a variant motherboard
where the only change is the connection of interrupts to PCI slots
without needing a kernel patch.
> Agreed with BIOS bugs ;-) Where probing is possible, is it reliable ?
I hereby define probing as only being possible where you get reliable
results. Thus PCI is included, pnp-ISA probably is, and straight-ISA
is not.
The one thing I am most against is having to make BIOS calls. It is
entirely too easy for a firmware constructor to be in a rush and mess
it up, and to crash the whole boot process.
> It'd take some baroque BIOS parameter table over yet another mandatory
> boot command line parameter any time ...
Definitely.
>
> > Hmm. I wonder how hard it would be to add -fPIC to the compilation
> > line for that file. But I'm not certain that would do what I want
> > in this instance...
>
> Are there actually architectures where the compiler generates
> position-dependent code even if you're careful ? (I.e. all functions
> inlined, only auto variables.)
O.k. I have looked, (I'm just polishing up my port to alpha). And yes
this can happen. It is not so much as the code being position
dependent as the code depending on the relative positions on the text
and data segments. On the alpha there a pointer to a globals area and
even using sufficiently large constants is enough to cause an access
to a static variable.
As for always having all functions inline and using only auto
variables, and no string constants, that is just asking for trouble.
When something goes wrong it is way to tempting to insert a bit of
debugging code and boom the code is broken.
Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/