[Alan Cox responded]
> Why not ?
Well, as you say below it is possible.
[More from Alan]
> 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 ?
Yeah I know about this. It's a step forward though. As most programs
have no use for FPU or emulation, especially on a router, it annoys me
that you currently have to have one or the other compiled in. I would
like to dump FPU support on a 386 router altogether, saving that 45kB or
so of emulation code.
[Alan Cox again]
> 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.
I didn't miss this, in fact I considered it. It would have involved
taking some rather hard parts of the kernel out and getting them into a
DOS program. It didn't seem like a good idea. Especially as I'd be
wanting Cyrix & AMD detection, and you know what trouble Cyrix has
caused lately...
Some of the boot loaders were on EPROM btw, not to mention that when a
floppy gets out and about, it stays out and about despite attempts to
force a new version around the place, so chopping and changing
repeatedly every time I had a neat idea was also not an option.
I also considered a kernel hack whereby the kernel (stripped down)
detects CPU type, SMP, FPU and some other things, then initiates a
_second_ reboot using a more specific and complete kernel. At least I
could have kept the detection code on the server that way. Actually
this was probably the best of all ways, but I didn't implement it.
As you say, only the fpu/nofpu part is easy, and as there's no run-time
speed overhead with always including the emulator, if anything I would
have modularised the emulation rather than hacked the boot loader. And
nop'ed out the FPU initialisation instruction from all the binaries and
crt1.o, changing the kernel default to match the application default.
[Martin Mares also pointed out]
> There is a very simple solution: Just make the `Simple DOS program'
> detect your CPU type and choose from two or three kernels available
> for remote booting.
See above. (1) not my program, I'd prefer not to have to hack it
(though I did have to add NE2K PCI support at one stage). (2) It's hard
enough to get the detection right in the kernel, especially detecting
genuine SMP.
-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu