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

[Thomas Gleixner]

On Mon, 2006-12-18 at 16:55 +0100, Robert Schwebel wrote:
> 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?

Who said, that UIO is the only way to access peripherals ? It's part of
the access methods. And as I said before: The access to the socket is
through the Framework System Interface and not something else. 

Framework Application Interface

	Protocol stack

Framework driver interface

	Driver

Framework system interface

The socket is accessed via the driver and the system interface. There is
no shortcut from the protocol stack to the socket, even if the driver
and the system interface would just map a socket to the
Framework-Driver-Interface. 

Furthermore this allows to 
- encapsulate the socket interface into a simple to handle interface for
the protocol stacks, instead of burdening each protocol stack with the
full socket handling
- implement protocol independent transport mechanisms. e.g. Ethercat can
encapsulate Sercos/CanOpen frames.

These layers are there on purpose and not to make a nice colored
picture: 

The layer interfaces _allow_ to verify source level and binary only
implementations of drivers and protocol stacks exactly by restricting
the interfaces to those which are provided by the framework.

If we even think about accepting or designing layering violations in the
first place, we can forget any attempt to verify and certificate
drivers / protocol stack implementations.

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

It is not part of the I/O framework and I'm not going to even think
about adding this feature. This is a complete seperate problem,
unrelated to I/O. 

I/O does _NOT_ need persistent storage and is _NOT_ related to
persistent storage. I/O is also not related to webservices, even if we
technically could add a webservice feature to it. 

Hell no, we are not going to design the all-in-one framework suitable
for every thing you might need in an industrial application. This is
about industrial I/O and nothing else.

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

No, it has not to be discussed. Such attempts are making a framework
concept moot per se. Please stop to try to inject _hardware_ specific
features into the framework itself.

If a driver and the data representation allows it to use such a feature,
fine, let the driver handle and implement it. If not, then the driver
has to do the necessary operations on the data to provide them in a
framework conform way to the users.

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

Right, but without violating the layer design itself. Every framework
will impose restrictions to specific hardware implementations for the
sake of clear interfaces, verification and interoperability. To achieve
this the framework _must_ be agnostic of such details. 

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

This is not nitpicking, this is a discussion about abstraction and layer
design and if we don't agree on a strict and non permissive design, we
can stop this whole effort right now.

	tglx