On Thu, Oct 8, 2009 at 7:37 PM, Philippe Gerum <r...@xenomai.org> wrote:
> On Thu, 2009-10-08 at 01:26 +0200, Alexis Berlemont wrote:
>> 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.
> This sounds like a plan, but this also raises a major concern: what's
> the status of your current code wrt the upcoming 2.5 now, given that you
> seem to imply that the current Comedi/RTDM tree does not exhibit the
> final architecture yet, and your proposal entails fundamental changes?
> It was made very clear during the recent XUM that 2.5 will be out this
> year, which leaves us with enough time to tackle the current issues, but
> likely not to reshuffle a complete framework.
> We could live with that framework only providing a single acquisition
> driver in 2.5.0, but the former has to be stable, and the ABI written in
> stone for the 2.5.x series. Provisions for transparent multi-ABI support
> might be acceptable, but this still requires to be confident about what
> would be needed in the long run, and that sudden change in your
> architecture is worrisome.

If I understand well, I have gone too far too soon; the idea should be
to keep the current framework as it is for 2.5.

However, my former mail was not a definitive plan. The first goal was
to share ideas. So, do not worry too much. :)

> In short, assuming your current work description eventually holds,
> what's your timing to deliver?

With my 1-2 hour(s) per night, I will need many months (at least 4).

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


Xenomai-core mailing list

Reply via email to