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

[Robert Schwebel]

On Mon, Dec 18, 2006 at 12:55:06PM +0100, Thomas Gleixner wrote:
> On Sun, 2006-12-17 at 15:34 +0100, Robert Schwebel wrote:
> > Thanks for providing this outline, I think it reflects the problem very
> > well. Some comments:
> > 
> > - OSADL protocoll stacks don't have necessarily to be put ontop of
> >   special OSADL userspace drivers, at least some will most probably 
> >   directly sit ontop of kernel/glibc infrastrukture like raw sockets.
> 
> No. This is exactly, what you want to avoid when you create a layered
> design. Drivers and stacks _can_ have empty implementations, but they
> have to be there in order not to violate the design.
> 
> Shortcut designs are evil and end up in the same desaster which one can
> observe with NDIS.

Whereas ...

On Thu, Dec 07, 2006 at 09:52:27AM +0100, Thomas Gleixner wrote:
> Es sind folgende Teilaspekte zu lösen:
> 
> 1) Zugriff auf die Netzwerkkarten ohne die existierenden Netzwerktreiber
> mit einer #ifdef Wüste zu überziehen
> 
> 2) Deterministischer Transport der Pakete von und zum Userspace
> 
> 3) Paketscheduling
> 
> 4) Userspace interface, auf dem der eigentliche Stack aufsetzt.
> 
> 5) Stackimplementierung im Userspace
> 
> 6) Einbindung des Stacks in das I/O Framework (Userspace Bibliothek)
> 
> Die ersten 5 Punkte sind erstmal unabhängig von der Framework
> Problematik und können parallel dazu gelöst und implementiert werden.

I don't understand your argumentation; IMHO your mail from Dec 07, quoted
above, does exactly reflect what I've said?

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. 

Let's for example take EtherCAT, what would we need:

- check what has to be done with network drivers to provide rt features,
  without cluttering with ifdefery

- check the Linux kernel's packet scheduling mechanisms and find out
  where the problems wrt. realtime are, provide alternate scheduling
  mechanisms with hrt 

- the interface between kernel and userspace is socket

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

So the image looks like this:

                       [...]

 +----------------------------------------------------+
 |        IIO Framework Driver Interface              |
 +----------------------------------------------------+
          |                               |
 +-------------------+          +---------------------+
 | User Space Driver |          | User Space Driver   |
 +-------------------+          +---------------------+
          |                               |
 +-------------------------+              |
 | IIO Framework System    |              |
 | Interface               |              |
 +-------------------------+              |
          |                               |
 +----------------------------------------------------+
 |   mmap(), read()  <-glibc-> socket(),recv(),send() |
 +----------------------------------------------------+
          |                               |
=+=========================+==========================+====
 |     UIO Framework       |     Socket Framework     |
 |                         +--------------------------+ 
 |                         |     Packet Scheduler     |
 |                         +------------+-------------+
 |                         |    NIC     |     NIC     |
 +-------------------------+------------+-------------+

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.

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

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

> > 1) We have to decide which kind of I/O we want to take care of: There is
> > a small border between low speed, more or less static I/Os, like for
> > example fieldbus I/Os, and high speed data aquisition devices like PCI
> > measurement cards or FPGA based data sources. Both have very similar
> > requirements wrt. data description, but very different performance
> > issues. High speed sources have more in common with AV codecs than with
> > a PLC process variable. We don't have to aim for completeness on the
> > first shot, but we should definitely take into account that the high
> > speed people would also want to use such a framework.
> 
> 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

> > 2) If we go the classical process-variables-in-shared-memory way, it is
> > important that the shm is discoverable. There must be some service that
> > can provide information like the location of a pv, it's data type and
> > length (for arrays), description, maybe physical unit. Some devices
> > provide these information automatically, others have things like EDS. In
> > modern object oriented and distributed systems, pvs or blocks of pvs
> > may be hot pluggable. The whole discovery service could be an addon,
> > nevertheless.
> 
> A) A process variable, the data which application level code deals with,
> is not necessarily related to I/O.

True. It can also be a local variable.
 
> B) Where is the difference between a shared memory image and an object
> oriented interface? You need description and discovery in any case and
> hotplug has to be there by default. modprobe kernel_driver is an hotplug
> event already.

I didn't say it is not possible, it was just a "these requirements have
to be fullfilled by our framework".

> > 3) Shms have to live on a backing store, for example battery buffered
> > static RAM. A framework needs to take care of the fact that there is
> > braindamaged hardware out there, like 8 bit FRAMs, being connected to a
> > 16 bit CPU bus, which means that you can access the bytes at offsets 0,
> > 2, 4 etc.
> 
> A) Why should I/O data be stored in persistant storage ? 

Not I/O data, but process variables.

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

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?

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