[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.021 / U:12.996 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site