Am Mittwoch, 18. Februar 2004 22:05 schrieb Enrico Weigelt:
btw: nvidia has found a moderate way of the trouble:
they've written a
small opensource stub driver, which loads the real binary driver and
dispatches the calls to its own binary interface.
which needs to be adapted for
more or less each single kernel revision. how
many kernel revisions appeared over the lifetime of Win2K?
does the windows version of exactly the same driver (the linux binary stub
models parts of the windows registry, so it's _really_ the same one) change
for each of these revisions, too?
You could also write generic driver interfaces / ABIs
for many device
types if you like / feel you require them. Of course this forbids many
compiler optimizations and so slows down a little bit in comparison
with "native" opensource drivers - but winnt has the same problem.
driver
code (esp for hardware) usually is not the bottleneck - much time is
spent in loops, waiting for the hardware, anyway.
ACK.
We've got the same problems in the mplayer project ... seems to be a quite
normal illness of coders ;-)
no, maybe these people are just tired explaining
things over and over again
and fighting the same battles uphill all the time..
it's easy to stand on top and laughing about those coming up to you while
kicking yet another stone in their direction - even when they might be right
(but you're only pretending to be interested in listening)
_that_ is why I'm getting pretty aggressive when I encounter behaviour that is
similar to that of (linux) fanboys (no idea about hyperion's motives to react
the way he does)
patrick mauritz