Date: Thu, 15 Mar 2001 19:03:19 -0800 (PST) From: Matthew Jacob <mjacob@feral.com> To: Matt Dillon <dillon@earth.backplane.com> Cc: John Baldwin <jhb@FreeBSD.ORG>, arch@FreeBSD.ORG Subject: Re: Proposal for the CPU interrupt API Message-ID: <Pine.BSF.4.21.0103151902320.75234-100000@beppo.feral.com> In-Reply-To: <200103160301.f2G31o955114@earth.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Thank you for your opinion. The functions currently exist, are useful, and will continue to be useful, and John's optimization makes sense. Next? On Thu, 15 Mar 2001, Matt Dillon wrote: > > :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?Pine.BSF.4.21.0103151902320.75234-100000>