Date: Thu, 15 Mar 2001 19:01:50 -0800 (PST) From: Matt Dillon <dillon@earth.backplane.com> To: Matthew Jacob <mjacob@feral.com> Cc: John Baldwin <jhb@FreeBSD.ORG>, arch@FreeBSD.ORG Subject: Re: Proposal for the CPU interrupt API Message-ID: <200103160301.f2G31o955114@earth.backplane.com> References: <Pine.BSF.4.21.0103151842370.75234-100000@beppo.feral.com>
next in thread | previous in thread | raw e-mail | index | archive | help
:Undefined. This depends on the architecture. Some architectures don't have a
:global interrupt lockout mechanism. Some architectures vary as to whether or
:not interrupts can be directed to one CPU, broadcast to all, or only for a
:specific CPU.
:
:I think it's safe to say that given your specific platform's interrupt
:mechanism, this disable_intr disables for this CPU only, or for all.
:
:This function should probably only be called from MD code. It's not very MI.
:The MI code has spin && adaptive locks and should be using just those. I can't
:imagine any case with the exception of debuggers and console I/O that might
:get terribly upset about this- in which case these subsystems have extensions
:into MD layers anyway.
:
:-matt
The functions wouldn't be all that useful if left undefined in this
manner. Consider why one might have to call such a function in the
first place...
* Your code could deadlock with an interrupt if it were to occur
on the same cpu, but it is ok for it to spin temporarily on another
cpu (aka a spin mutex).
* Your code could deadlock with an interrupt if it were to occur on
any cpu (not a spin mutex, but something more severe)
* Your code is time-sensitive and cannot suffer a long interruption
(interrupt on current cpu. aka the IDE byte stuffing bug of
several years ago).
* Your code is time-sensitive and code sensitive because you wrote
it badly and it cannot suffer any interruption (interrupt on any
cpu) (lets not mention DMA here).
Unless you define precisely what this API is supposed to do, even if
it is intended to be a machine-dependant API, the procedures will be
almost completely useless. At worst they will be used with assumptions
that are incorrect, or may break in a port to another cpu (remember,
a lot of the PCI driver code is machine-independant!), or other bad
things might happen. Interrupt disablement code is not something which
can be defined willy-nilly! You need to be precise.
-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?200103160301.f2G31o955114>