Date: Sat, 18 Mar 2000 13:12:39 -0800 (PST) From: Matthew Jacob <mjacob@feral.com> To: Warner Losh <imp@village.org> Cc: hackers@FreeBSD.ORG Subject: Re: splFoo() question Message-ID: <Pine.BSF.4.05.10003181306530.89834-100000@semuta.feral.com> In-Reply-To: <200003182031.NAA97975@harmony.village.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.05.10003181306530.89834-100000>