[ag-automation] OSADL: Working-Group I/O-Framework, Echtzeit-Ethernet

[Robert Schwebel]

On Mon, Dec 18, 2006 at 04:31:20PM +0100, Thomas Gleixner wrote:
> No, it does not. It looks still the same way as in my schematics. There
> are no shortcuts in a layered design. Period.

Correct me if I'm wrong: UIO is there to access memory mapped
peripherals and to get interrupts from kernel to userspace in a well
defined way, nothing more and nothing less. How can a userspace
implementation access the glibc socket API only by using the UIO
infrastructure then, without re-implementing the nic drivers?

> Can you please look at the scheme I provided and tell me, why it is
> restricted to fieldbusses? An onboard digital I/O is just a special
> form of a fieldbus and has its own (empty) stack and a driver. But you
> still need mapping and association of process objects to it.

Ok, if you see it this way you are right.

> > > B) Persitant storage is completely unrelated to I/O and fieldbus drivers
> > > and stacks
> > 
> > I didn't say it is related, but it is part of the application stack. 
> 
> This has nothing to do with the I/O framework. This is a seperate
> problem. Can we restrict this discussion to the I/O topic please?

It is impossible to add this kind of feature if you don't take care of
it in the design from the beginning. So it is ontopic here.

> > If you want to take care of high rate data, the hardware driver
> > (kernel or uio userspace) has to deliver a message directly, maybe
> > via DMA, into the process variable shm, without an additional copy.
> 
> No. It does not DMA into a process variable. This simply can _not_
> work in a generalized model.

That's why I said that one has to take the usage scenario into account.
You cannot have both -> topic has to be discussed.

> Even if the hardware can DMA the data into userspace, there is an
> userspace driver, which knows how to deal with that particular data
> representation. The framework is agnostic of such details, otherwise it
> would not be a framework.

Yes, but it has to take care that it is possible to transport the data
in the most performant way. 

> > Can you give us an impression which primitives the IIO Framework Driver
> > Interface and IIO Framework Application Interface could have, or should
> > we postpone this discussion until the working group meeting?
> 
> I had no time yet to document that.

I suppose most of the issues will be clearer when a more detailed
outline is available. So let's postpone the nitpicking until then.

Robert
-- 
 Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
 Pengutronix - Linux Solutions for Science and Industry
   Handelsregister:  Amtsgericht Hildesheim, HRA 2686
     Hannoversche Str. 2, 31134 Hildesheim, Germany
   Phone: +49-5121-206917-0 |  Fax: +49-5121-206917-9