Members of Project UDI today announced the release of the UDI (Uniform
Driver Interface) 1.0 Specification. This Specification is the
culmination of a multi-company development effort designed to provide
device driver portability for existing and future system configurations.
UDI supports today's key I/O technologies and is designed with an
extensible architecture that can easily accommodate future I/O
technologies and products.
Project home page: http://www.projectudi.org/
Specificiations (PDF): http://stage.sco.com/udi/f-specs-1.0.html
Story link:
http://www.newsalert.com/bin/story?StoryId=Cn8YKWbKbyteXmt&FQ=linux&SymHdl=1&Nav=na-search-&StoryTitle=linux
No thanks, IMHO OS neutral driver interfaces are a nice idea but they
can only lead to mediocrity. (Yes I have read and understand how your
stuff works, the problem will still be there).
Later,
David S. Miller
[email protected]
Alan Cox wrote:
> Not sure why anyone thinks this is Linux relevant 8) - other than it will help
> to make our drivers even faster than the competition if they adopt it.
> Have a read, but keep a bucket handy
In response to you and David: I agree :) But if vendors take this
seriously, I have a feeling a UDI interface will eventually appear.
Lack of UDI support may be an encouragement or a discouragement,
depending on the complexity of the device driver.
On a related subject, I think Linux could use a much more coherent --
and documented -- device driver interface. Writing portable Linux
device drivers requires very in-depth knowledge of the Linux 'arch'
code; I find myself checking the Alpha or Sparc arch code a lot to make
sure that the I/O routines and such that I call work as expected.
Regards,
Jeff
--
Americans' greatest fear is that America will turn out to have been a
phenomenon, not a civilization.
-- Shirley Hazzard, "Transit of Venus"
On Wed, 01 Sep 1999, Jeff Garzik wrote:
(...)
> On a related subject, I think Linux could use a much more coherent --
> and documented -- device driver interface.
Yes. And I'll need to sort some of that out for the Driver Programming
Interface (DPI) anyway. (See Audiality site; Downloads.) I basically need to
re-implement the calls as versions that can be called from RTLinux pthreads. It
would also be nice if everything could be kept compatible on the source level.
That's why I didn't like the original rtl_posixio module. (Have yet to release
my real version - with the *real* structs instead of my binary level
compatibles in 0.1.0...) I also have a problem with code like
current->state = TASK_INTERRUPTIBLE;
and the like. Not too nice to #define into something else, not related to
current or task_struct...
set_current_state(TASK_INTERRUPTIBLE);
Is a lot nicer. However, implementing things like that for no other reason but
to hide the underlying details (which, AFAIK, wasn't the case with this
example) is not as nice as it may sound in real life... Abstraction can be
dangerous. I'll have to do some in the DPI, but I'm afraid there's a risk
that the resulting API won't fit too well as a new driver API for standard
kernels.
OTOH, if RTLinux is ever going into the standard kernels, I think being able to
compile some drivers for it is essential. It's kind of pointless to most users
otherwise...
//David
?A?U?D?I?A?L?I?T?Y? P r o f e s s i o n a l L i n u x A u d i o
- - ------------------------------------------------------------- - -
?Rock Solid David Olofson:
?Low Latency http://www.angelfire.com/or/audiality ?Audio Hacker
?Plug-Ins [email protected] ?Linux Advocate
?Open Source ?Singer/Composer