Philippe Gerum 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. > > In short, assuming your current work description eventually holds, > what's your timing to deliver?
Given that we did not deliver a stable version with comedi/analogy support yet, what about declaring the whole thing "experimental" or "unstable" (/wrt to its ABI) until the dust settled. That way any user building some application on top if it would do this on his own risk. Jan
Description: OpenPGP digital signature
_______________________________________________ Xenomai-core mailing list Xenomaiemail@example.com https://mail.gna.org/listinfo/xenomai-core