Artur Skawina writes:
> Albert D. Cahalan wrote:
>> Digital UNIX (now Tru64, was OSF/1) uses self-modifying code to
>> create a generic kernel that can do, if I remember right:
>>
>> 1. plain
>> 2. real-time
>> 3. SMP
>> 4. real-time SMP
>> 5. lock debugging
>>
>> So, if you don't want these features, you only suffer some NOPs and
>> perhaps sub-optimal register allocation.
...
>> Other uses for this technique include: Generic kernels could run
>> on a real i386 without being slow on a 486. Modules could work for
>> SMP, huge memory, and normal kernels. Exact process accounting could
>> be part of every kernel, but NOPed out at runtime if not enabled.
>
> Doing this (ie omitting stuff like all spinlocks, accounting etc code)
> would be fairly easy (by intelligently linking at load time), and yes,
No, linking isn't good enough. Many of these are inline assembly.
Even when not, one would want to completely eliminate function calls.
> the price would be in register allocation. But what about data
> structures?.. Either you'd have to leave them alone, in which case the
> "generic" kernel would eg be faster on UP than on MP, but would still
> not be as efficient as a dedicated UP one;
Yes, exactly.
> IOW, making a generic kernel a bit more efficient when certain
> features aren't needed is possible, but the price isn't only worse
> register allcation. (yep, some things can be done at runtime, but the
> only feature from the above list i can see this making sense for is
> bypassing the rt layer when it's not in use)
You aren't thinking like a distribution or hardware vendor.
Distributions use modules, even though compiled-in drivers are
more efficient. Until recently, distributions didn't do SMP.
Many distributions (still?) compile kernels for a real 80386.
Even if a hardware vendor ships source code, they may still want
to ship binary drivers for popular distributions. (and when they
don't also ship source, SMP users currently get left out)
Currently we have a nasty symbol-mangling system to prevent people
from loading SMP modules into a uniprocessor kernel. This wouldn't
be so important if every uniprocessor kernel could handle the code.
For tech support, it is nice to be able to tell someone to boot
with an option to enable lock checking or some sort of trace code.
This is easier than explaining, over the phone to someone clueless,
how to compile and/or install a new kernel.
-
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/
This archive was generated by hypermail 2b29 : Fri Jul 07 2000 - 21:00:12 EST