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/