[lkml]   [2000]   [Jul]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: a joint letter on low latency and Linux
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
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:57    [W:0.085 / U:47.920 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site