Universal Driver Interface spec available

Universal Driver Interface spec available

[Jeff Garzik]

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

-
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/

Re: Universal Driver Interface spec available

[David S. Miller]

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
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/

Re: Universal Driver Interface spec available

[Alan Cox]

> 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

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



-
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/

Re: Universal Driver Interface spec available

[Jeff Garzik]

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"

-
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/

Re: Universal Driver Interface spec available

[David Olofson]

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    www.angelfire.com/or/audiality   ·Audio Hacker
    ·Plug-Ins            audiality@swipnet.se        ·Linux Advocate
    ·Open Source                                     ·Singer/Composer

-
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/