Date: Mon, 6 Jun 2005 08:34:37 +0200 From: "Norbert Koch" <NKoch@demig.de> To: "Maksim Yevmenkin" <maksim.yevmenkin@savvis.net> Cc: "Freebsd-Hackers@Freebsd. Org" <freebsd-hackers@freebsd.org> Subject: RE: synchronization question about /sys/dev/vkbd/vkbd.c Message-ID: <008001c56a61$cf92bf00$4801a8c0@ws-ew-3.W2KDEMIG> In-Reply-To: <42A090DE.8060002@savvis.net>
next in thread | previous in thread | raw e-mail | index | archive | help
> > My question is: > > Is it not possible, that vkbd_dev_intr() could be > > interrupted at any position before the VKBD_LOCK() > > and then vkbd_dev_write() called? > > in theory it is possible. > > > If yes, how should vkbd_dev_write() know, that it should > > call task_enqueue(), as TASK is still set? > > well, i guess it is possible to miss interrupt in this case. also, the > scancodes are not lost, they will be processed on next write. > I agree, that it is hardly possible to miss an interrupt, as keys come in so slowly. But that also means if it happens, you will notice it, because you have to press an additional key. > i suspect that the vkbd_dev_intr() should be interrupted exactly > in between > > (*kbdsw[kbd->kb_index]->intr)(kbd, NULL); > > and > > VKBD_LOCK(state); > Yes, precisely. > yes, that could be done. it is also possible to have a callout going few > times a second to check if there is a scancodes in the queue and > schedule vkbd_dev_intr(). funny that atkbd(4) and ukbd(4) have just this. Thank you for your comments, Norbert
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?008001c56a61$cf92bf00$4801a8c0>