Date: Wed, 29 Nov 1995 22:11:08 +1100 From: Bruce Evans <bde@zeta.org.au> To: hackers@FreeBSD.ORG, msmith@atrad.adelaide.edu.au Subject: Re: more device driver question 8) Message-ID: <199511291111.WAA18017@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>Driver read routine sets up buffers, etc. >Driver enables interrupts on peripheral. > Peripheral immediately interrupts, may satisfy whole read request. >Driver goes to sleep waiting for read request to be satsified. >... >I can't see how to avoid this race; I'm sure it must be possible, but >browsing other drivers yields no immediate inspiration. >Some sleep at raised interrupt level: >spltty() > tsleep(...) >splx() >Does this imply that tsleep() restores the base interrupt level while >it's running? Of course. Other process may run while the driver is sleeping. They may run in user mode. The sleep may be arbitarily long. It is not good to block interrupts for aritrarily long :-). After the tsleep(), the driver state may have changed in ways that are limited only by the exclusivity of access to the driver and/or how the driver handles i/o's and ioctls for other processes. If it blocks in _all_ cases then then state can't change (except for interrupts). Otherwise it has to check for state changes after each sleep. See tty.c for both good and bad examples. i/o's for separate processes are allowed to interleave... Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199511291111.WAA18017>