Date: Thu, 06 Apr 2000 20:22:59 -0400
From: Jeff Garzik <jgarzik@mandrakesoft.com>
Disclaimers: I haven't read the code yet, and no, I don't work for
ImageStream :)
Now that's some ugly code...
If it helps WAN people write WAN drivers, so be it, but it's
not something I'd like to let into the main tree. I mean,
they redirect kmalloc calls, kmalloc of all things. What they
really are trying to do is have only to port this SAND DDK thing
if we make changes in the kernel, and never have to touch the drivers
themselves. So essentially they make their own binary driver interface
to decrease the amount of recompilation they need to do.
Redirecting things like kmalloc is actually potentially bad for
performance. For example, say some day we use inline macro expansion
and GCC's builtin_constant_p() on the length being requested to figure
out the SLAB pool at compile time. With kmalloc call redirection,
they won't get that optimization. Same goes for potential SMP
lock and atomic operation implementations, often the code can be
compiled in a significantly more efficient manner if constants and
other invariants are exposed.
So perhaps their press release is really about making binary only
drivers more feasible and maintainable. It's quite pointless, they've
just moved their problem into another place, instead of having to have
different individual driver binaries when kernel APIs change, one
needs to get a new recompiled version of their silly library. It
hasn't solved the problem, is just makes it different.
It's much like the "DDK like" thing SCO and others were pushing for
a Linux implementation of, the core incentive is the same, make binary
only drivers more feasible under Linux. This is why all of these
efforts tend to smell bad to me.
It's amusing how so many companies want to have that Linux checkbox,
and the extremes they'll go to in order to retain binary only drivers
at the same time.
Later,
David S. Miller
davem@redhat.com
-
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 Apr 07 2000 - 21:00:17 EST