From owner-freebsd-hackers Sat Mar 18 13:12:54 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 33E0C37B7D6 for ; Sat, 18 Mar 2000 13:12:48 -0800 (PST) (envelope-from mjacob@feral.com) Received: from semuta.feral.com (semuta [192.67.166.70]) by feral.com (8.9.3/8.9.3) with ESMTP id NAA23399; Sat, 18 Mar 2000 13:12:39 -0800 Date: Sat, 18 Mar 2000 13:12:39 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: Warner Losh Cc: hackers@FreeBSD.ORG Subject: Re: splFoo() question In-Reply-To: <200003182031.NAA97975@harmony.village.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Shouldn't all of this should be properties of the newbus code? There should be some value that is associated with any device that says "I need to disable receiving interrupts from this device". This could then fold into an MP spinlock case that honors device interrupts. What you're describing below *is* machine dependent, but very similar to the ddi_iblock_cookie_t for Solaris, which also then had the related ddi_idevice_cookie_t (which would have the bits appropriate for programming 'programmable' interrupt levels)- but considering it 'newbus' dependent is certainly better sounding than "machine dependent". I'm eager to hear if there's a way already to do this in FreeBSD. On Sat, 18 Mar 2000, Warner Losh wrote: > > I'd like to be able to do some simple spl locking in a driver that I'm > writing. While I could go the splhigh() route, I'm concerned that > spending lots of time at splhigh could cause problems, and some of my > critical sections look to be very expensive. They only need > protection against the card itself, not against the entire system. It > just seems to be an overly large hammer. > > In addition to the driver I'm working on now, I've watned to do this > in the pccard system so that we block interrupts for the cards when > we're mucking around with the pccard bridge chipset on eject events. > Right now, I'm using splhigh() for that, but that strikes me as > excessive. > > I've wanted to do something like this for a long time, so I thought > I'd spend some time diving down into the spl code and digging around. > Always a dangerous thing to do, I know. > > My first thought was to use splx, but that's for lowering the spl (eg > clearing bits) rather than raising it. > > So instead, I'd like to have a code that looks like: > s = splirq(n); > ... > splx(s); > in my code. > > A nieve implementation would be > > static __inline int splirq(int n) > { > int oldcpl; > > oldcpl = cpl; > cpl |= (1 << n); > return oldcpl; > } > > This strikes me rather dangerous, machine dependent, and making unwise > assumptions. It wouldn't work on MP. I'm sure that there are lots of > other reasons that this won't work which aren't immediately obvious... > > Except for shift vs mask differences, this looks identical to the splq > code in the UP case. I also notice that splq doesn't appear in the > spl(9) man page and thus might disappear in the future. I further > notice that it appears to be a i386 only routine, appearing only in: > i386/include/lock.h > i386/isa/intr_machdep.c > i386/isa/intr_machdep.h > i386/isa/ipl_funcs.c > > There's got to be a simple, MI way to do things like this, but I'm not > sure that I'm seeing any. > > Warner > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message