Messages in this thread | | | From | "Albert D. Cahalan" <> | Subject | Re: a joint letter on low latency and Linux | Date | Tue, 4 Jul 2000 03:35:39 -0400 (EDT) |
| |
Artur Skawina writes: > Albert D. Cahalan wrote:
>> 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
Sure, that works, but I wouldn't call it "linking".
>> 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.
If you can avoid wasting memory, this is great.
>> 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
It isn't just for them. The binary+source vendors can use it too. Many users will want binaries, even if source is available.
> "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...
No, you can use a pure PentiumIII-SMP kernel as long as it provides the code-modification services for generic modules. Compiled-in drivers simply don't call (or trap to) the self-modification engine.
>> 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.
It is extra effort to ensure that the two kernels are identical in all ways except debugging support.
- 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/
| |