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

[Thomas Gleixner]

On Mon, 2006-12-18 at 14:13 +0100, Robert Schwebel wrote:
> IMHO you can't seriously propose that you will duplicate all network
> card drivers in "OSADL User Space Drivers", which would be the same
> concept currently used in dual kernel implementations like RTnet. 

No. I never did and the above points are not contradictionary to a
layered design model.

> - the interface between kernel and userspace is socket

Yes, but how does that affect layers ? And the socket is the interface
between the kernel and the Framework System Interface. Nothing above
that accesses a socket directly.

> - an OSADL userspace protocol stack would get it's messages/packets via
>   standard POSIX socket API, do all the state machine & protocol
>   handling and offer the IIO framework application interface.

Nope. It get's it via a driver, which uses the abstract socket interface
provided by the Framework System interface. The protocol stack itself
knows nothing about a socket at all. The protocol stack uses the
framework driver API and nothing else. Even if the framework driver API
looks like a socket, it still is not a socket. 

> So the image looks like this:

No, it does not. It looks still the same way as in my schematics. There
are no shortcuts in a layered design. Period.

> The requirements are:
> 
> - If today some company wants to provide a proprietary stack, it must be
>   possible in userspace.
> 
> - If in the future there is enough critical mass on the market to
>   develop an OSS replacement and if the kernel is technically the right
>   place to do so, it must be possible.

Look at the proposed scheme. It contains exactly that. Red ==
proprietrary. I forgot to add this to the legend, but ....

> I don't know the details wrt. EtherCAT, but for example if you take the
> CAN example, we don't want to go back to the times where everyone
> invents his own random CAN API. Nevertheless, it must be possible to
> write adapter code in userspace which either sits ontop of the SocketCAN
> API or ontop of any other crude industrial CAN driver, but offers the
> same unified OSADL API (probably what you call IIO Framework Application
> Interface).

Who said that we want to have random APIs ? That's why we need a strict
layered design.

> > > - What do you mean with FABI?
> > 
> > Fieldbus (Independent) ABI.
> >  - Mapping functions of process variables to I/O
> >  - ....
> 
> Note that we don't only care about fieldbus. Fieldbus is one scenario,
> but not the only one. An IO frameowork should make fieldbus work
> possible but not be centered on fieldbus.

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.

> > Why is there a big difference. It's mainly an issue of the driver
> > implementation and the way the device / driver presents the data.
> 
> Has to be discussed. The two scenarios are
> 
> - data comes in and is processed at some time in the future, if the
>   application is interested in it
> 
> - data comes in and is streamed to some sink, maybe with closed loop
>   requirements

Aarg. This is an implementation detail.
  
> > 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 ?

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

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.

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

	tglx