Subject: Re: IPL_LOCK oddity
To: Manuel Bouyer <bouyer@antioche.eu.org>
From: Bill Studenmund <wrstuden@netbsd.org>
List: tech-kern
Date: 08/24/2006 10:55:42
--SUOF0GtieIMvvwua
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, Aug 24, 2006 at 09:38:11AM +0200, Manuel Bouyer wrote:
> On Thu, Aug 24, 2006 at 12:18:12PM +0900, YAMAMOTO Takashi wrote:
> > > In chatting with dbj, I was reminded that on a number of ports, we ha=
ve=20
> > > IPL_SERIAL higher than IPL_LOCK. IPL_IPI also is higher than IPL_LOCK=
 on=20
> > > x86 (I didn't check extensively).
> >=20
> > > Also, is the IPI code structured so that it doesn't have to take lock=
s?
> >=20
> > x86 ipi code uses raw __cpu_simple_lock for that reason.
>=20
> And maybe the serial code should use that too ... The locks here are not
> supposed to be hold for long times, from what I remember.

That would probably be the best solution. I'd rather not have spllock()=20
block serial interrupts.

The one problem is that the lock that the com driver takes for interrupts=
=20
is also the one it takes for normal uses. The latter uses may want to stay=
=20
with normal spin locks. If so, that'd be an arguement against changing=20
serial drivers to use __cpu_simple_lock.

I just talked myself into and out of something. :-|

Thoughts?

Take care,

Bill

--SUOF0GtieIMvvwua
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (NetBSD)

iD8DBQFE7egeWz+3JHUci9cRAnC9AJ0WXDytOxhFyS6SyjY/sv1k7fCi/ACdEZxy
TF1Z6M2ZseKyf7lycuMbWqg=
=CEdW
-----END PGP SIGNATURE-----

--SUOF0GtieIMvvwua--