Mailing List Archive

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/

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

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/

In article <linux.kernel.E11MI2e-0003fR-00@the-village.bc.nu>,
Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>> Members of Project UDI today announced the release of the UDI (Uniform
>> Driver Interface) 1.0 Specification. This Specification is the
>Not sure why anyone thinks this is Linux relevant
a) Embrace and extend: ``Come, join us; if you write Linux device drivers
you won't have to write drivers for anyone else.''
b) Losing the job security of having to rewrite drivers every time a new
major release comes out.
It might be better to have a native driver interface, but for #1 I'm not
picky; I'd like to have a NCR810 driver that worked again.
____
david parsons \bi/ 2mb of pdf. Ugh. Hopefully they've got a nice
\/ reference map among the formatting.
-
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/

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/

>>>>> "Jeff" == Jeff Garzik <jgarzik@pobox.com> writes:
Jeff> 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
Jeff> In response to you and David: I agree :) But if vendors take
Jeff> this seriously, I have a feeling a UDI interface will eventually
Jeff> appear. Lack of UDI support may be an encouragement or a
Jeff> discouragement, depending on the complexity of the device
Jeff> driver.
Linux has proven so far to be able to get vendors to provide
documentation for real drivers - whether they only plan to provide
Lose9x/NT drivers or UDI ones is pretty irrelevant. If they want Linux
users as their customers they need to provide specs so we can get real
drivers, enough vendors got the clue so far, so buy from them.
Nice theory, useless in practice. I read about half the spec a year
ago and I can only say that unless they redid the whole thing it's
still nothing but a bad joke.
Jeff> On a related subject, I think Linux could use a much more
Jeff> coherent -- and documented -- device driver interface. Writing
Jeff> portable Linux device drivers requires very in-depth knowledge
Jeff> of the Linux 'arch' code; I find myself checking the Alpha or
Jeff> Sparc arch code a lot to make sure that the I/O routines and
Jeff> such that I call work as expected.
It's not too hard writing portable drivers as long as you don't do
stupid things like type casting pointers to integers and stop thinking
the world is little endian only and thus use bitops on char *
etc. (not trying to be promote myself as a guru on this, but I think
the AceNIC Gigabit Ethernet driver is a reasonable example of how this
can be done in a pretty clean way - drivers/net/acenic.[ch] - I am
going to submit a new and better version to Linus today I hope).
I agree that there are a few things that could use more documentation,
however we needed to sort out a thing like the behavior of
readl/writel first.
Jes
-
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/

> 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.
Actually there are a couple of reasons it is relevant to Linux.
There is already code out there to run UDI drivers on a Linux system. If you
look, one of the demonstration systems was a Linux system. Intel did the
port.
Intel has also made statements to the effect of reference drivers for it's
hardware are most likely going to be UDI. If this happens, you are going to
want UDI support just so you can bring up new Intel hardware fast.
With some work on the UDI interface, you should be able to make it so all
UDI drivers are RTLinux friendly. Also, you could change the
mutex/semaphore/locking code as many times as your little hearts desire
without having to rewrite every UDI driver. The UDI interface has all of the
mutex and timed waits happening outside the driver, in the UDI support
routines.
I would have thought that people would rather spend their time working on
improving the operating system rather than rewrite an ethernet or SCSI
device driver for the umpteenth time. That is what UDI is intended to allow
you to do, focus on the OS and use standard drivers.
> 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.
How about just a documented driver interface that doesn't change? The
interface has changed for EVERY KERNEL VERSION lately.
The 2.0 drivers had to be modified for 2.2. I believe I've seen indications
that further SMP patches will make it necessary to change the drivers again
for 2.4, although I haven't found any documentation that clearly spells this
out.
Where is the documentation on writing drivers for Linux? I've got the Rubini
book, which is stuck back in kernel version 1.2 for a lot of stuff. There
are enough changes where none of his examples compile correctly under 2.2.
It wasn't until I started compiling stuff that I found out that the PCI
interface had changed, I have no idea how many other things have changed
since the time of the book.
-Bret
-------------------------------------------------------------
SBS Technologies, Connectivity Products
... solutions for real-time connectivity
Bret Indrelee, Engineer
SBS Technologies, Inc., Connectivity Products
1284 Corporate Center Drive, St. Paul MN 55121
Direct: (651) 905-4731
Main: (651) 905-4700 Fax: (651) 905-4701
E-mail: bindrelee@sbs-cp.com http://www.sbs.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/

> Intel has also made statements to the effect of reference drivers for it's
> hardware are most likely going to be UDI. If this happens, you are going to
> want UDI support just so you can bring up new Intel hardware fast.
Slowly you mean. I've read the UDI spec in detail. Its about fit for BIOS
loaders but thats it. If intel provide source it will be worth porting their
drivers to the OS properly. If intel don't provide source we don't care anyway.
You simply cannot express stuff like the linux parport sharing in UDI, its
got no equivalence. Out goes parallel devices. You can't portably express
the Linux tty layer, out go tty devices. It's too slow for serious networking
and it can't properly express our scsi stuff and make good use of it.
So what are you going to do with it. Joysticks ?
> With some work on the UDI interface, you should be able to make it so all
> UDI drivers are RTLinux friendly. Also, you could change the
> mutex/semaphore/locking code as many times as your little hearts desire
> without having to rewrite every UDI driver. The UDI interface has all of the
> mutex and timed waits happening outside the driver, in the UDI support
> routines.
Which can have very long lock holding times. Not funny at all.
> I would have thought that people would rather spend their time working on
> improving the operating system rather than rewrite an ethernet or SCSI
> device driver for the umpteenth time. That is what UDI is intended to allow
> you to do, focus on the OS and use standard drivers.
UDI can't correctly express the Linux resource management in a portable way,
nor the memory allocator, nor the layering stuff.
> How about just a documented driver interface that doesn't change? The
> interface has changed for EVERY KERNEL VERSION lately.
If you dont change you get the windows 98 problem.
> The 2.0 drivers had to be modified for 2.2. I believe I've seen indications
> that further SMP patches will make it necessary to change the drivers again
> for 2.4, although I haven't found any documentation that clearly spells this
> out.
Yes some will. But as with 2.0 the changes so far to do a simple job are
easy.
> Where is the documentation on writing drivers for Linux? I've got the Rubini
> book, which is stuck back in kernel version 1.2 for a lot of stuff. There
> are enough changes where none of his examples compile correctly under 2.2.
> It wasn't until I started compiling stuff that I found out that the PCI
> interface had changed, I have no idea how many other things have changed
> since the time of the book.
Rubini's book is apparently being updated. I have written a set of articles
for Linux Magazine on 2.0->2.2 conversions - you can grab them from
O'Reilly's web site or buy the magazine 8)
There is a project going on to write a complete, thorough Linux kernel
book on the net. There are 2 or 3 other kernel books too.
Alan
-
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/

Hi David.
Are you sure your email address is correct? That's how your recent
emails have reached me, but it looks to be wrong...
> ____
> david parsons \bi/ 2mb of pdf. Ugh. Hopefully they've got a nice
> \/ reference map among the formatting.
Have you had a look at some of the semiconductor data sheets that are
available in pdf format? The largest to date was too large for a Zip
disk !!!
Best wishes from Riley.
+----------------------------------------------------------------------+
| There is something frustrating about the quality and speed of Linux |
| development, ie., the quality is too high and the speed is too high, |
| in other words, I can implement this XXXX feature, but I bet someone |
| else has already done so and is just about to release their patch. |
+----------------------------------------------------------------------+
* ftp://ftp.MemAlpha.cx/pub/rhw/Linux
* http://www.MemAlpha.cx/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/

Alan Cox wrote:
> Bret Indrelee wrote:
> > Intel has also made statements to the effect of reference
> drivers for it's
> > hardware are most likely going to be UDI. If this happens,
> you are going to
> > want UDI support just so you can bring up new Intel hardware fast.
>
> Slowly you mean. I've read the UDI spec in detail. Its about
> fit for BIOS
> loaders but thats it. If intel provide source it will be
> worth porting their
> drivers to the OS properly. If intel don't provide source we
> don't care anyway.
>
> You simply cannot express stuff like the linux parport
> sharing in UDI, its
> got no equivalence. Out goes parallel devices. You can't
> portably express
> the Linux tty layer, out go tty devices. It's too slow for
> serious networking
> and it can't properly express our scsi stuff and make good use of it.
Could you please tell me, or better yet write to the UDI tech mailing list,
with some of the performance problems you see?
The spec as written right now should be good for SCSI and networking.
It depends on what you mean by tty stuff, if it is just UARTs/DUARTs/etc
then it should be fine. If you are trying to integrate it with pseudo-tty
and other services I think that is outside what UDI was attempting to do.
You would put that in the UDI implementation, only using a UDI driver for
the actual serial port.
I've been on the UDI tech mailing list for quite a while, yet haven't seen
any postings from you with suggestions on how to improve performance. I
haven't gone through the public comments, perhaps you put them there?
If you see something wrong, you should point it out. I know that there will
be another revision of the spec, they still need to work out all of the
bridge mechanics as well as a few other issues.
> So what are you going to do with it. Joysticks ?
>
> > With some work on the UDI interface, you should be able to
> make it so all
> > UDI drivers are RTLinux friendly. Also, you could change the
> > mutex/semaphore/locking code as many times as your little
> hearts desire
> > without having to rewrite every UDI driver. The UDI
> interface has all of the
> > mutex and timed waits happening outside the driver, in the
> UDI support
> > routines.
>
> Which can have very long lock holding times. Not funny at all.
If there are long locking times, it isn't UDIs fault. It is the fault of the
UDI implementation or the OS. The device drivers themselves don't do the
waiting, they exit and allow the region locking mechanism within UDI handle
when to call back.
The drivers in UDI do not do mutexs. If anything, it should make things
perform better on a real time system than they used to.
[ snip ]
> UDI can't correctly express the Linux resource management in
> a portable way,
> nor the memory allocator, nor the layering stuff.
Does it need to? Why can't the OS do this, just tell the driver where to put
the data?
[ snip ]
> > Where is the documentation on writing drivers for Linux?
> I've got the Rubini
> > book, which is stuck back in kernel version 1.2 for a lot
> of stuff. There
> > are enough changes where none of his examples compile
> correctly under 2.2.
> > It wasn't until I started compiling stuff that I found out
> that the PCI
> > interface had changed, I have no idea how many other things
> have changed
> > since the time of the book.
>
> Rubini's book is apparently being updated. I have written a
> set of articles
> for Linux Magazine on 2.0->2.2 conversions - you can grab them from
> O'Reilly's web site or buy the magazine 8)
Got it and read it before I started. It fails to mention that PCI access was
redone.
It does mention the interrupts, SMP, and init sections.
So what other surprises am I going to hit as I try to implement my Linux
driver? I've already had to reference the kernel source a couple of times
just to figure out the return types of a few functions.
The other thing you could do is point me to a well done loadable module
character driver. Preferably one done for PCI that does bus mastering and
uses MODULE_PARM() to allow some customization.
[ snip ]
-Bret
-------------------------------------------------------------
SBS Technologies, Connectivity Products
... solutions for real-time connectivity
Bret Indrelee, Engineer
SBS Technologies, Inc., Connectivity Products
1284 Corporate Center Drive, St. Paul MN 55121
Direct: (651) 905-4731
Main: (651) 905-4700 Fax: (651) 905-4701
E-mail: bindrelee@sbs-cp.com http://www.sbs.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/

> I've been on the UDI tech mailing list for quite a while, yet haven't seen
> any postings from you with suggestions on how to improve performance. I
> haven't gone through the public comments, perhaps you put them there?
No. I read the 0.9 spec. I thought "oh dear". I read the 1.0 spec and thought
"oh well"
> waiting, they exit and allow the region locking mechanism within UDI handle
> when to call back.
> The drivers in UDI do not do mutexs. If anything, it should make things
> perform better on a real time system than they used to.
I can see that isa win for RtLinux
> > a portable way,
> > nor the memory allocator, nor the layering stuff.
>
> Does it need to? Why can't the OS do this, just tell the driver where to put
> the data?
Linux doesnt permit memory allocation in a block I/O handler. Linux
supports blocking memory allocations all sorts of places which UDI can't
express.
> > for Linux Magazine on 2.0->2.2 conversions - you can grab them from
> > O'Reilly's web site or buy the magazine 8)
>
> Got it and read it before I started. It fails to mention that PCI access was
> redone.
Read it again. It tells you that the old PCI methods still work.
> So what other surprises am I going to hit as I try to implement my Linux
> driver? I've already had to reference the kernel source a couple of times
> just to figure out the return types of a few functions.
The kernel source is the reference.
> The other thing you could do is point me to a well done loadable module
> character driver. Preferably one done for PCI that does bus mastering and
> uses MODULE_PARM() to allow some customization.
drivers/char/synclink.c is the only character driver making major use of
PCI bus mastering in simple ways (the video capture stuff tends to write
scripts for video engines so its less than intuitive). The network
drivers are a much easier read for that. Basically its
buf=kmalloc(size, GFP_KERNEL);
if(buf==NULL)
sulk();

phys_addr = virt_to_bus(buf);
write_buffer_out();
mb(); /* stop the compiler from any sneaky saves in registers */
poke_hardware(phys_addr);
Then whenever you are told the buffer is done continue with it.
The only horrible case to watch is terminating a live DMA. PCI does write
posting so doing
writel(STOP_DMA, card->control);
kfree(buf);
is fatal every so often, as the write will be posted, the buffer freed,
reallocated and trashed before the DMA is posted. Instead use
writel(STOP_DMA, card->control);
readl(card->anythingboring);
kfree(buf);
Alan
-
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/

Bret Indrelee wrote:
> If you see something wrong, you should point it out. I know that there will
> be another revision of the spec, they still need to work out all of the
> bridge mechanics as well as a few other issues.
Then why was a "1.0 final" spec released?
> The drivers in UDI do not do mutexs. If anything, it should make things
> perform better on a real time system than they used to.
So UDI drivers break on SMP systems? Or will Linux UDI lock the entire
kernel while its doing its work?
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/

> Bret Indrelee wrote:
> > If you see something wrong, you should point it out. I know
> that there will
> > be another revision of the spec, they still need to work
> out all of the
> > bridge mechanics as well as a few other issues.
>
> Then why was a "1.0 final" spec released?
The specification is complete for everything that it covers. Right now,
there are some things that can't be handled by UDI that will be added in
future versions of the specification.
Your question is about like asking "Why do we need a UNIX98 specification
when we have POSIX?"
In my opinion, the group came out with a very workable specification. It
doesn't cover everything right now, but it does cover the dominate devices
such as disk and network interface cards. They had to get it out there so
more people could start implementing with it.
> > The drivers in UDI do not do mutexs. If anything, it should
> make things
> > perform better on a real time system than they used to.
>
> So UDI drivers break on SMP systems? Or will Linux UDI lock
> the entire
> kernel while its doing its work?
The UDI implementation does the locking, not the device driver. The device
driver just uses the regions. If for some brain-damaged reason a UDI
implementation decides to only have a single lock for every device, that
isn't because of anything in the UDI specification. It would just be a bad
implementation of UDI.
The current bugs with SMP drivers changing the current state would be fixed
in the UDI implementation software, not each UDI driver using it. Fix it in
one source file, not each driver that comes out.
-Bret
-------------------------------------------------------------
SBS Technologies, Connectivity Products
... solutions for real-time connectivity
Bret Indrelee, Engineer
SBS Technologies, Inc., Connectivity Products
1284 Corporate Center Drive, St. Paul MN 55121
Direct: (651) 905-4731
Main: (651) 905-4700 Fax: (651) 905-4701
E-mail: bindrelee@sbs-cp.com http://www.sbs.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/