Hi,
The last week, I have been working on the global architecture of the analogy
project.
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
(ex.
irq).
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
an
"attach" callback is called within the driver.
- The comedi core is in charge of routing the ioctls to the proper
subdevice
callbacks.
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
model
(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
application.
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
framework.
Feedbacks welcome.
Alexis.
_______________________________________________
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
