Re: COMMAND_LINE_SIZE increasing in 2.6.11-rc1-bk6

[ebiederm@xmission.com (Eric W. Biederman)]

Werner Almesberger <wa@almesberger.net> writes:

> Eric W. Biederman wrote:
> > Something like that.    I have yet to see a even a proof of concept
> > of the idea of passing device information, to clean up probes.
> 
> Yes, the kexec-based boot loader first, then this. For a
> kexec-based boot loader, passing device scan results will be
> very useful, plus it's a good environment for experimenting
> with such a feature.

And from another perspective what drives things are practical
requirements.  Boot speed while nice does not yet seem to be a
driver, and that is all I have seen proposed with passing
the list of hardware.  What is currently a driver in
the kexec scenario is booting a kernel without firmware
calls, and in the kexec-on-panic case booting a kernel
without a kernel where the hardware is in a known messed
up state.

So far I have seen nothing that even resembles an architecture
independent solution to avoiding firmware calls.  And right
now I'm not even certain I even expect to see something it become
architecture independent.  At the very least we need some
clean architecture specific support first, so we can have
a clue what needs to be generalized.  ia64 and ppc are coming...

At any rate I see the problem of which hardware devices
are present as a subset of the problem of booting without firmware.
So I suspect we are going to get some pretty weird architecture
specific implementations at least in the first go round.

Eric