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. I suppose the x86 version
> of this could be a debug breakpoint byte followed by a byte to indicate
> the required operation -- lock, unlock, or whatever. One might also
> be able to make the assembler spit out addresses, like the exception
> table code does.
>
> 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,
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; or you could fix up all
references, but then this becomes much too complicated. At that point
I'd prefer to simply have a two+ stage boot process where the final
kernel is recompiled (possibly from some kind of precompiled form to
speed this up) to match the hardware. Or you could have all possible
versions of the code prebuilt and link only the required objects on boot.
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)
-
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:11 EST