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/
This archive was generated by hypermail 2b29 : Wed Apr 23 2003 - 22:00:17 EST