Date: Sat, 18 Mar 2000 13:31:28 -0700 From: Warner Losh <imp@village.org> To: hackers@freebsd.org Subject: splFoo() question Message-ID: <200003182031.NAA97975@harmony.village.org>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200003182031.NAA97975>