- From: Calin A. Culianu <calin_at_ajvar.org>
- Date: Fri, 9 Aug 2002 15:22:47 -0400 (EDT)
> > Actually, I agree, at least for read insn from user-space. It probably > wouldn't be appropriate for kcomedilib with all the RT expectations. It > would not require much modification of drivers, except adding a field that > lets a driver specify the settling times it needs. The core module could > keep track of what the last range was and if it has changed. Dave, what do > you think? > This is great Frank.. I'm glad we agree. :) My argument, however, if I may continue to push it with you guys.. :).. is that even in kcomedilib it should be done as well. Motivation: The driver should be as intelligent and useful as possible. It should not return unusable values when doing a rinsn, just because we want it to return as fast as possible in RT. There is a deterministic upper bound on how long a rinsn would take on a given machine and board/driver combo in RT -- even with the udelay() between multiplexer setup and the inw to read the channel registers. Without the udelay() the returned value is not to be trusted.... since we really are breaking the spec of the board. I know one can just issue a wait whenever changing channels, or maybe port over comedi_data_read_delay() to kcomedilib, or something similar -- ..but that approach detracts from the overall simplicity of using the kcomedilib interface (which really in general I find quite programmer-friendly and quite expressive). Why make the programmer -- even if he is a hardk0re kernel programmer writing realtime code -- do some of the work of the driver in keeping with his board's specs? And why make board-specific code present in the application (even if the application happens to have components that run in kernel context)? -Calin
Received on 2002-08-09Z18:22:47