![]() | ||||||||||
Messages in this thread |
Hi George, hi Keith, hi lkml, On Mon, Apr 14, 2003 at 02:49:39PM -0700, george anzinger wrote: > Ingo Oeser wrote: > > On Fri, Apr 11, 2003 at 02:21:38PM -0700, george anzinger wrote: > > > >>Ingo Oeser wrote: > Yes, I believe this is what RTLinux and RTIA do. The sti macro then > needs to check for pending interrupt work, much as the bh_unlock does. Ok, NOW we are talking ;-) > > Not suitable for drivers. They must read the registers, set some > > other registers and ACK the IRQ in the ISR. There is no way > > around that. > > The lock has two sides, the reader and the writer. The writer still > takes the irq/ spinlock, only the reader gets the speed up. But the read can read garbage and may need a retry. This is not acceptable for me, since one of my cards will do destructive reads. They implement a hardware FIFO (of one element depth), where the register I read from is removing the element while reading. This is a common design you'll find in PCI-bridge chips (I used the S5933 from AMCC for this). So this scheme still doesn't help me and is not the proper drop-in replacement, we are looking for. BTW: Please note, that you can assume I know the semantics of all the locking functions currently in Linus' tree. So you can stop explaining me the details of them and continue with defining a proper cli/sti replacement. Thanks! > > So if there would be a schedule_work_deadline() then this would > > be nice. The routine called later in process context called will > > be noticed, if the deadline is missed or not and can act > > correctly. [...] > > We currently have timers, but they are not suitable for doing the > > work only for triggering it and that's a source of complexity in > > driver design. > > Something of this sort is present in the workqueues design. There is > a schedule work for later call. Yes, but it doesn't solve the problem, that I've illustrated. You'll not know, WHEN this scheduled work will trigger (kernel tells us: ASAP) and you need another kernel thingie again. And you must check, whether the deadline is over yourself. This isn't that nice design. I just don't feel that experienced, that I can change the scheduler. But maybe we can talk about that now, that we both know that we know the current kernel API well enough ;-) Regards Ingo Oeser - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ | |||||||||
| Last update: 2005-03-22 12:34 [from the cache] ©2003-2008 | ||||||||||