Date: Thu, 15 Mar 2001 19:38:19 -0800 (PST) From: Matt Dillon <dillon@earth.backplane.com> To: John Baldwin <jhb@FreeBSD.org> Cc: Matthew Jacob <mjacob@feral.com>, arch@FreeBSD.org Subject: Re: Proposal for the CPU interrupt API Message-ID: <200103160338.f2G3cJs55363@earth.backplane.com> References: <XFMail.010315190611.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
:Yep. I think that on the Alpha the IPL may be shared among all CPU's or may be
:per-CPU but I'm not sure. On the x86 it would only be for the local CPU, but
:all that any calling code should depend on is that it disables interrupts for
:the current CPU.
Well, if the IPL is shared amoung all CPU's then for disable_intr() or
work as advertised it would have to keep a reference count, since you
might have several cpu's disabling interrupts at the same time. That
would imply that every call to disable_intr() or enable_intr() must be
matched by a call to restore_intr().
The documentation of the API is very important. It's perfectly
acceptable to document the api as "Always disables hard interrupts on
the current cpu and may or may not also disable hard interrupts on
other cpus. All calls to disable/enable must be matched with a
restore". It is not acceptable to document the API to be completely
different for one cpu or another. e.g. it is not acceptable to document
the API as "Always disables hard interrupts on the current cpu for
i386 and always disables hard interrupts for all cpu's for Alpha. You
don't have to match up calls on i386 but you do have to match them up
on Alpha". The procedure's implementation on specific cpu's could in
fact allow that, but if programmers were to actually program to that
in potentially shared code (and many device drivers are shared across
cpu's), the result is going to be a huge mess.
And as far as your inane comments go, Matt... if you stopped to actually
read my posting you might have understood my issue a little better. I
don't know where you got your attitude problem or why you are being so
combative, and I'm not interested either.
-Matt
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200103160338.f2G3cJs55363>