Albert D. Cahalan wrote:
>
> > 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.
No, "smart" linking of the kernel at boot time is enough to eliminate
the useless code. For example, here is what you can do:
instead of generating the spinlock code (it's an asm() anyway) you just
mark the place where it would have been used (eg by placing the address
in some .init section). Then the boottime "linker" (loader) can figure
out whether the code is necessary (based on hw detection and/or user
input) and add it. The runtime cost is just in the register allocation
(any registers that are used by the inline code will be treated in the
same way, even if the inline code isn't there). Yep, you have to make
sure that the assembler generates relocation records even for things
it thinks it knows the addresses of (which might require minor tweaks
to the build tools, esp. as this should be selective in order not to
penalize short branches).
> > 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.
Actually, like a distribution -- yes; like a driver vendor --
no, that is beyond the scope of this. See below though.
> Distributions use modules, even though compiled-in drivers are
> more efficient. Until recently, distributions didn't do SMP.
Ideally, there shouldn't be any difference between a "module"
and "compiled in driver", and hopefully that will be the case
in the near future.
> 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.
So you are proposing to make the kernel less efficient so that
binary only driver vendors have it easier? Because once such a
"generic kernel" option is there they will use it, and then it's
no longer really optional if you happen to need just one driver
w/o source... I don't have anything against binary kernel modules,
and i think that supporting them would be a good thing, but as a
side effect of having an otherwise very useful infrastructure,
not by adding unnecessary limitations.
[the scheme described above could be used to make "generic"
loadable modules. It's just that it becomes quite complex,
and at that point it's probably not worth it. Hence the
"precompiled modules" idea mentioned in the previous message.]
> 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.
This can already done by providing a generic for-debugging-only
kernel. And some things can be enabled at runtime, eg you should
be able to replace the locking code with your own versions (and back).
I'm already doing this with the ip checksums, and the locking code
seems even simplier -- because of the static nature and known
out-of-line portions. Hmm, except the new spin_unlock() (which is
just memory store, hence harder to locate).
-
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:13 EST