The last week, I have been working on the global architecture of the analogy 

I tried to sum-up the main characteristics of Comedi. That was a start to 
figure out what shape analogy will get.

Here are some notes on that subject:

1) Comedi drivers are not common Linux drivers. In these drivers:
        - there is neither fops structure nor ioctl operations
        - there is, of course, no cdev registration
        - The Linux API is sometimes wrapped into Comedi-specific functions 

2) Comedi imposes a specific organization: devices are composed of subdevices 
which are themselves composed of channels. Then a Comedi driver:
        - declares a list of subdevices
        - displays a list of callbacks per subdevices (command, instructions, 
trigger, etc.).

3) The Comedi midlayer is the link between the Linux driver programming model 
and the Comedi drivers:
        - The Comedi core manages a set of pre-registered character devices
        - Via a specific ioctl, the core assigns a dev file to some driver and 
"attach" callback is called within the driver.
        - The comedi core is in charge of routing the ioctls to the proper 

According to me, this architecture brings some troubles:
1) Not all the drivers perfectly fit into the midlayer:
        - Some components of acquisition cards do not comply with the subdevice 
(ex. the mite in NI card). 
        - We find card specific declarations in the Comedi core layer (ex.: 
some NI 
specific counter modes in comedi.h);
2) On the user space side, it is difficult to write a card independant 

All these points make me think that the idea of midlayer itself is not 
suitable in our case. Because of the fact that the drivers do not fit well 
into the generic programing model, we find ourselves adapting user space 
programs to the card they will use.

I would rather propose a framework composed of helper modules. Analogy drivers 
would be quite similar with common RTDM drivers (they would contain fops 
declarations, dev registrations, etc.); 

As a consequence, Analogy will be a set of tools:
        - ioctl routing function
        - acquisition device registration
        - asynchronous buffer management modules
        - etc.

Eventually, instead of rewriting the whole Comedi drivers suite. I think we 
can develop an analogy driver which will route the analogy ioctls to the 
proper Comedi subdevice callbacks. I think everybody will agree to consider 
this point critical. We must retrieve the Comedi drivers as easy as possible.

Many things need to be thought twice but I am quite convinced such a solution 
is feasible.

If some people disagree or have other prospects in mind, I am looking forward 
to reading them.

I think I will create a new branch in my git repository (analogy...) to push 
ugly and non-working code. The idea is to quickly show the shape of Analogy 

Feedbacks welcome.


Xenomai-core mailing list

Reply via email to