Why not ?
> However it must always work with _all_ the PCs if possible. It cannot
> even note the CPU type the first time a client is run, and use a kernel
> optimised for that client in future, because the users (they're
> programmers) have a habit of changing their computers around without
> telling anyone, and fiddling with their part of the network.
You are missing something simple here 8)
> That is why I am interested in an Pentium/SMP optimised kernel that is
> 386/UP compatible. As it was, I had to make do with the 386 compatible
> kernel with FPU emulation compiled in, the lowest common denominator and
> probably the largest kernel. BTW, thanks to the person who made FPU
> emulation into a module recently.
Actually the FPU module isnt ideal. For glibc at least I seem to get
insmod using FPU which might be a bit fatal. Better would be to create
an __fpucode __fpudata linked before the __initcode/__initdata and discard
more if an FPU is not needed - have you look at that Adam btw ?
Right the cluon you missed. Make your bootp/kernel loading client check
the CPU type and the fpu/nofpu and smp settings then ask tftp for an
image of
vmlinuz-[no]smp-[456]86-[no]fpu
Fixing the fpu/nofpu is easy. Fixing the 386/486 nicely is very hard,
smp/nosmp is very hard.
This sort of 'load the right bit' trick btw is how the sparc ultralinux loads
either a sun32 or sun64 kernel image..
Alan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu