Kendall> Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>> Not really. The binary format is dependant on compiler,
>> architecture, SMPness and a dozen other things. The source is not.
Kendall> As I said above, all these problems are solveable. You can
Kendall> solve these problems easily by making sure your interfaces
Kendall> handle things correctly. There are ways to normalise
Kendall> differences between compilers, and compatibility tests are
Kendall> what you should use to check this.
Kendall> Take XFree86 4.0 for instance. They support binary loadable
Kendall> modules and they don't have these problems.
First major thing XFree does not have to deal with is SMP, the API for
threaded applications in user space is independant of whether a system
is a multi processor box or not ... this is not the case of the
kernel. There are two ways to get around this in the kernel, one to
call a regular function which then knows whether to play spin lock or
just return or make the inline spin lock macros much bigger ... both
will cause unnecessary overhead and latency.
Please tell me why we should even bother wasting our time on this
issue just to make a minority of vendors happy who still naiively
believe that revealing source to drive their hardware makes
competitors able to copy it. The only other reasonable explanation
here is that those vendors are embarrassed about the quality of their
code.
Jes
-
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/