lkml.org 
[lkml]   [2000]   [Nov]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Q: Linux rebooting directly into linux.
Eric W. Biederman wrote:
> The code wasn't trivially reusable, and the structures had a lot
> of overhead.

There's some overhead, but I think it's not too bad. I'll give it a
try ...

> The rebooting is done the rest is not yet.

Ah, and I already wondered where in all the APIC code you've hidden
the magic to avoid the config data clobbering issues ;-)

> 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.

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.

And, besides, I think it complicates the kernel, because you either
have to add a parallel set of functions extracting and processing data
from the "native" or the UBE environment, or you have to add a converter
between "native" and UBE for each platform. Or do you have a better
plan ?

When I started with bootimg, I also thought that we'd need some
parameter passing mechanism, a bit similar to UBE (although I would
have tried to be more text-based). Then I realized that there are
actually only a few tables, and we can just keep them in memory. And
some of them need to be modified before we can re-use them. (Trivial
example: the boot command line. Video modes are a similar, although
much more complicated issue.)

> Besides which most tables seem to contain a lot of information that
> is probeable. Which just makes them a waste of BIOS space, and
> sources of bugs.

Agreed with BIOS bugs ;-) Where probing is possible, is it reliable ?
It'd take some baroque BIOS parameter table over yet another mandatory
boot command line parameter any time ...

> 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.)

- Werner

--
_________________________________________________________________________
/ Werner Almesberger, ICA, EPFL, CH Werner.Almesberger@epfl.ch /
/_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_____________________/
-
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/

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