> I'm thinking of a specific scenario that I have had to maintain in
> the past:
> Q> All the company's PC run Windows normally. Occasionally there is
> Q> use for running Linux on one of these PCs, to demo a program,
> Q> run a test, run as an X terminal, diagnose hardware, or just to
> Q> advocate Linux a bit...
> Q> There is NO possibility that Linux may be installed on any of
> Q> these Windows machines. Repartitioning is out of the question,
> Q> and touching the disk at all is often not accepted. A few
> Q> machines do have Linux installed; those machines only ever run
> Q> Linux.
> Q> A Linux server provides a complete diskless NFS-root installation
> Q> to any machine that requests it, on demand. Hard links and clever
> Q> scripts keep the storage requirements down, and the network
> Q> configurations for each are generated from templates. NFS
> Q> swapping is also used. These installations cannot all be prepared
> Q> "by hand" in advance because there are too many _potential_
> Q> clients, most of which will never run Linux but we don't want to
> Q> rule any out by deciding which are supported clients and which
> Q> are not.
> Q> A simple DOS program is run on any PC, off a floppy disk, which
> Q> loads the kernel over the network.
The obvious route to take in this case would be to let the DOS program
determine which processor is in use and load a kernel optimised for
use with that processor, which would deal with a fair sized chunk of
your problem scenario. It's not that hard to detect both processor
family and presence of an FPU, and the latter test is only needed if
the processor test says 386 or 486 anyway...
Lemme see, something along the lones of the following pseudo-code
should do that...
Q> CPU="Standard processor detection code"
Q> if (CPU=8086 or CPU=80286) then
Q> print "Linux needs an i386 or better processor to run."
Q> print "This system only has an $CPU processor, sorry."
Q> error 1
Q> endif
Q> if (CPU=i386 or CPU=i486) then
Q> MPU="Standard FPU detection code"
Q> else
Q> MPU=YES
Q> endif
Q> nfsboot "Linux-$CPU-$FPU"
Alternatively, have the CPU emulation compiled as a module, using the
recently devised modular interface to it, in which case, the above
pseudo-code reduces to...
Q> CPU="Standard processor detection code"
Q> if (CPU<i386) then
Q> print "Linux needs an i386 or better processor to run."
Q> print "This system only has an $CPU processor, sorry."
Q> error 1
Q> endif
Q> nfsboot "Linux-$CPU"
Obviously I'm missing something important here, so perhaps somebody
could indicate what...
> Q> The kernel autodetects the hardware and simply boots up, not
> Q> touching the client's disk. Often, up pops Xdm and the Windows
> Q> user is amazed :-) Really, it just boots and works. Sometimes a
> Q> bit of per machine configuration is needed, but only for X and
> Q> the mouse. Console mode always works.
That's as it should be...
> Q> It is not acceptable to spend time "hand installing" anything,
> Q> or going through a standard distribution installation. The
> Q> administrative time cannot be justified. (And it just works
> Q> anyway...).
Why would any be needed in the first place?
> Q> Some PCs are Pentiums and PPros, some 486s, some are 386s acting
> Q> as cheap printer servers (not even a monitor or keyboard on
> Q> those).
I do the same on my private network...
> Q> There is no central database of what machines are connected that
> Q> may wish to use this service.
None is needed...
> Q> Often Linux is run in this way just to find out what is in a
> Q> machine! :-)
I do the same with machines I come across...
> In the above scenario, I would very much like to run a kernel
> optimised for the PC it is running on. That is not possible
> unfortunately.
Why on earth not? The loader can easily have the level of intelligence
outlined above, in which case you AUTOMAGICALLY get a kernel optimised
for the system it's running on...
> The next best thing would be a kernel optimised for most of the
> PCs. 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.
There's NO need whatsoever for it to make ANY note about what it
encountered on ANY previous run. The proposed loader would quite
happily ensure that the CORRECT kernel for the CURRENT configuration
was used, even if it's now a 386sx/16 and the previous run was on a
P9/40000 (if any such processor ever appears) !!!
> 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.
I'm still at a loss to understand why you HAD to do that?
> BTW, thanks to the person who made FPU emulation into a module
> recently.
I'll second that...
Best wishes from Riley.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu