Subject: Re: Console polling programming interface change (proposal)
To: None <eeh@netbsd.org>
From: Jaromír <jdolecek@netbsd.org>
List: tech-kern
Date: 07/20/2001 20:40:49
eeh@netbsd.org wrote:
> Which specific drivers are involved? Which cnpollc() and cngetc()
> routines are called?
pckbc, pccons
> Which interrupt routines are being triggered?
pckbcintr(), pcintr()
> Is there no way to block the interrupt in that driver?
Nothing besides spl I'm aware of. The idea of cookie was precisely
so that it would be possible to call spltty() in pckbc's cnpollc()
entry point and pass spltty()'s return value to upper layer.
> Is there no way to acknowledge the interrupt without reading the
> input byte(s)?
Seems to not be. It seems common pc kbd controllers either
ack the interrupt when status byte is read, or it worked by luck
since commonly ISA interrupts are edge triggered and hence can't stay
unacknowledged.
> Why do you consider fixing this in the driver by passing the byte
> from the interrupt handler to the getc routine uglier than changing
> all MI code that usess cnpollc()?
It seemed that would involve dirty hacks to pckbc/pccons driver, and it
seemed cleaner to adapt MI interface to support such quirks.
However, I've now actually tried to implement it and it turned out to
be not too bad (see my previous post).
Thanks
Jaromir
--
Jaromir Dolecek <jdolecek@NetBSD.org> http://www.ics.muni.cz/~dolecek/
NetBSD - just plain best OS! -=*=- Got spare MCA cards or docs? Hand me them!