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/
This archive was generated by hypermail 2b29 : Fri Jul 07 2000 - 21:00:14 EST