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

[Thomas Gleixner]

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.

> - What do you mean with FABI?

Fieldbus (Independent) ABI.
 - Mapping functions of process variables to I/O
 - ....

> Some further remarks:
> 
> 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.

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

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.

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

B) Persitant storage is completely unrelated to I/O and fieldbus drivers
and stacks

C) If you want to create a backing store framework, then such a
framework does not care at all about hardware oddities. Thats what an
hardware driver (kernel and/or userspace) takes care off.

> 4) We have to decide if a framework will only use a "polling" model,
> like processes running in cycles and doing things "once per cycle", or
> if we also want to take care of "event" type activities.

The framework has to deal with both models.

	tglx