- From: Calin A. Culianu <calin_at_ajvar.org>
- Date: Thu, 13 Jun 2002 18:21:18 -0400 (EDT)
Hmm. Personally I am not sure what that would buy, since user code would still look kind of messy in the case where the instruction list failed. Do you think long instruction lists some of the time are something people would use? Me: I prefer the determinism of sticking to the hard limit now. Those are my $0.02. :) Also -- I was just wondering if this 9 insn constant was available to clients of the library? I skimmed the header files but nothing jumped out at me (I could have missed it though).... -Calin On Thu, 13 Jun 2002, David Schleef wrote: > On Thu, Jun 13, 2002 at 04:52:16PM -0400, Calin A. Culianu wrote: > > > > For some reason, comedi_do_insnlist() produces bogus data whenever I > > specify more than 9 consecutive read instructions in the same instruction > > list (reads on different channels, but still reads). Is this due to some > > limitation in the kernel side's copy_from_user() (since I understand with > > a lot of instructions in an array, the size of the memory area to be > > copied to kernel space can get large) or to some other limitation in > > comedi? > > It's an arbitrary limit in the code. It's necessary to balance > the needs of the rest of the OS, since the machine is effectively > locked while processing instructions. The same reasoning is > responsible for the insn.n<=128 limit. > > A better solution would be to check if there is another task > waiting to be scheduled (this is common in drivers), and return > prematurely. A minimum number of instructions should always > be non-preemptible, though. This matter is open for discussion. > > > > dave... > > > > _______________________________________________ > comedi mailing list > comedi_at_stm.lbl.gov > http://stm.lbl.gov/cgi-bin/mailman/listinfo/comedi >
Received on 2002-06-13Z21:21:18