And as far as performance hits? I understand where you are coming from on
this, and i fell that when (and i suppose IF) UDI is implemeneted in the
Linux kernel then special attention should be paid to exactly HOW the
interface is defined and implemented for the kernel. I don't
see that just because it is a standardized driver interface that a given
driver would be any slower. Again, with a well laid interface (both at
high and low levels of code AND design) it wouldn't matter. Granted, I
see your point that given a poor design, a generic interface by which all
devices are used, all devices may suffer a performance loss. But who's to
say that UDI will require a 'vanilla' interface where you 'plug in' a
driver and teh kernel decides to do with it as it wishes? Would it not be
possible to write a UDI device driver interface and then use that
interface to tie drivers more closely into say, networking code, or
video code?
The UDI specification has been in development for years (which is a bad
sign) by committee. It was designed without any consideration of what
would or would not be convenient for Linux.
e.g. becasue teh driver is UDI it give us the ability to utilize that
driver using a UDI spec. A UDI spec should not be so dimwitted that
there's an extra layer of code between teh driver and it's 'controller'.
Take a look at the API specifications, and judge for yourselves.
Myself, I'd guess that a native will always be faster, because among
other things, I don't see how to avoid at least one or two extra memory
copies when you are using the UDI interfaces.
- Ted
-
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/