Date: Wed, 29 Nov 1995 09:27:22 +0000 () From: Michael Smith <msmith@atrad.adelaide.edu.au> To: julian@ref.tfs.com (Julian Elischer) Cc: msmith@atrad.adelaide.edu.au, hackers@freebsd.org Subject: Re: more device driver question 8) Message-ID: <199511290927.JAA11541@genesis.atrad.adelaide.edu.au> In-Reply-To: <199511290922.BAA01693@ref.tfs.com> from "Julian Elischer" at Nov 29, 95 01:22:14 am
next in thread | previous in thread | raw e-mail | index | archive | help
Julian Elischer stands accused of saying: > > 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? > exactly, > It schedules another process, which will be at some OTHER > interrupt priority level, it does it 'atomicly' too.. Ah. This implies that interrupt priorities are kept on a per-process basis, correct? So for a 'tty' device driver, I could safely say spltty() enable_interrupt() tsleep() splx() and be sure that interrupts from the device won't be enabled until after the current process sleeps? Thanks. -- ]] Mike Smith, Software Engineer msmith@atrad.adelaide.edu.au [[ ]] Genesis Software genesis@atrad.adelaide.edu.au [[ ]] High-speed data acquisition and (GSM mobile) 041-122-496 [[ ]] realtime instrument control (ph/fax) +61-8-267-3039 [[ ]] "Who does BSD?" "We do Chucky, we do." [[
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199511290927.JAA11541>