Re: Kernels > 1M

H. Peter Anvin (hpa@transmeta.com)
Mon, 09 Aug 1999 02:50:54 -0700

Dominik Kubla wrote:
>=20
> On Mon, Aug 09, 1999 at 10:36:00AM +0200, Werner Almesberger wrote:
>=20
> > Considering that nothing but bootsect.S itself uses syssize, the mo=
st
> > straightforward solution to the problem seems to be to change the u=
nit
> > of syssize from paragraphs to sectors, to increase the header versi=
on
> > number in setup.S (not 100% clean, but the best approximation to a
> > version number for bootsect.S we have), and to update the checks
> > accordingly.
> >
>=20
> Hi Werner et al.,
>=20
> how about dropping the boot and setup code from the kernel ent=
irely?
> Just move the whole stuff to the bootloader (as it used to be=
done
> with commercial Unices on PC's) and have it setup the whole 32B=
it PM
> environment, load the (possibly zipped) vmlinux binary (not necessar=
ily in
> this order), pass the config options on the command line (or throug=
h some
> reserved memory) and execute it.
>=20
> Thus we would no longer need as86/ld86 to build the kernel (see the =
thread
> about this topic) and building the kernel would be the same =
as on
> SPARC/MIPS/ALPHA...

bootsect.S could definitely be dropped, but I personally suspect it
would be a mistake to drop the setup. Otherwise the dependencies
between boot loader and kernel would be a lot more painful.
=20
> The next step then would be to merge MILO(Alpha), MILO(Mips), LILO an=
d SILO
> (Werner. we talked about that over dinner back at Linux-Kongre=
ss in
> W=FCrzburg, remember?) into a common bootloader for all architectur=
es. That
> should make life a bit easier for the distributors and documen=
tation
> authors ...
>=20
> Are there any _REAL_ problems that would prevent this?

Well, except for the fact that booting is so incredibly different on
different architectures...

It would probably be quite a bit easier with the "lbcon" boot loader I'=
m
currently working on, if only because it runs in a 32-bit environment
and most of it is C code, compiled with gcc. That doesn't mean that
there needs to be code that is substantially different between the
various architectures.

The main reason I'm writing lbcon is because I think it will make doing
fancy stuff with initrd a lot less painful, and it should be easy to pu=
t
a nice user interface on it. That's the theory, at least...

-hpa

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel"=
in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/