[ag-automation] FDDI (Fieldbus Device Driver Interface) Update

[Robert Schwebel]

On Mon, Jun 18, 2007 at 06:25:53PM +0200, Dieter Hess wrote:
> here is an updated version of the FDDI:

Thank you very much for this contribution! It is good to see the ball
rolling again. Our currently three custom fieldbus porting projects are
making heavy progress; nevertheless, they involve proprietary stack code
of one of the big manufacturers, so we cannot use this as an example for
the stack development. Nevertheless, it's some more test cases which can
work out the pros and contras.

Btw, your mailer config is borked; it should break lines at something
like < 78 lines.

> - fddi.h: the header file for the fddi (updated)
> - fddi.c: a prototype implementation of fddi (compilable but not
>   tested) to better understand how fddi is meant to work

I've added this revision and all the earlier ones to the OSADL SVN
repository, at this location:

	https://www.osadl.org/svn/osadl/software/fieldbus-framework

	rsc at thebe:~/svn/osadl/software/fieldbus-framework$ ls -l
	total 16
	drwxr-sr-x 5 rsc ptx 4096 Jun 18 19:40 fddi-20070502-1
	drwxr-sr-x 5 rsc ptx 4096 Jun 18 19:32 fddi-20070529-1
	drwxr-sr-x 5 rsc ptx 4096 Jun 18 19:17 fddi-20070618-1
	drwxr-sr-x 5 rsc ptx 4096 Jun 18 19:44 fddi-trunk

As you can see, I've put the versions you've posted into the date
stamped directories, plus copied the last version into -trunk. Please
let's use trunk for further code progress, to get a consistent code
history. I hope anyone involved is familiar with svn; please let me know
if not and we'll see how we can change this quickly.

> Some remarks:

> - The implementation in fddi.c is just a prototype, to get the idea
>   how it is working. I know that there are a lot of improvements like
>   error handling, more dynamic data structures etc.

Yup. I can add some makefiles, to make it possible to build it easily.

> - I didn't rework fddi.h regarding coding guidelines, because I don't
>   know the coding guidelines right now. Of course I have no problems to
>   follow the coding guidelines, but I would do it in a second step.

Well, we should simply follow kernel coding style. It is whidespread,
commonly used in this community and we should aim for consistent code
all over the kernel/userspace border.

If we have agreed on the svn workflow, it's easy to change the coding
style.

> - To test the fddi at least two other modules are needed:
>
>   - A Fieldbus Device Driver (for example a CANopen Stack) including a
>     definition for configuration
>   - An application using the fddi

[...]

> As I am not planning to implement a fieldbus stack in the near future
> I would be happy if someone else will do this using the fddi. For
> definitions of configuration profiles I have suggestions for CANopen,
> Profibus, EtherCAT, SERCOS III and ProfiNet. But I will wait until
> someone write a real stack, because formatting them definitions is
> quite a lot of work.

Hmm, we should start with something which is known to be easy. I'll
check what we have available; it must be somehting open, because in
order to validate the mechanisms it must be discussable in public.

Could you check my remarks to your last version? I've quoted it below
for reference. Most of the questions are still valid.

On Tue, May 29, 2007 at 10:04:23AM +0200, Dieter Hess wrote:
> The header contains all data types and all functions of the fddi.

See my comments below. Btw, it would be better to post these things
inline, because it makes quoting & review easier.

For the final header files we should make sure the lines are smaller
than 80 characters.

> The following things are planned to be delivered in the next few days:
> 
> - an implementation proposal for the fddi
> - a definition of configuration profile for a field bus protocol
>   (which should we use as a first example? We at 3S have definitions for
>   CANopen, Profibus, EtherCat and SERCOS III)

Some use cases would also be a good thing, just to get the picture how
these things are supposte to work.

> /* fieldbus device driver interface */

Header files should clearly state a license; I'd suggest LGPL or BSD, to
make proprietary and oss programs possible.

> /* #include "lldi.h" */
> typedef void *LL_INTERFACE;
> 
> /* result codes */

Please use the normal errno return values, which would be ...

#define RESOK 0					0 (no need to define something here)
#define RESERR_INTERFACE_ALREADY_REGISTERD 1	EBUSY
#define RESERR_LLINTERFACE_ALREADY_IN_USE 2	EBUSY
#define RESERR_LLINTERFACE_HAS_WRONG_TYPE 3	?
#define RESERR_OUT_OF_MEM 4			ENOMEM
#define RESERR_TIMEOUT 5			ETIMEDOUT
#define RESERR_NO_ACCESS 6			EACC
#define RESERR_BUFFER_TO_SMALL 7		ENOBUFS
#define RESERR_WRONGTPUTYPE 8			?

> /* io-interface */
> struct _io_interface

Why the underscore?

> {
> 	char* name;				/* name of the interface */
> 	unsigned long version;	/* version of the interface */
> 

Regards,
Robert Schwebel
-- 
 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