From owner-freebsd-arch Thu Mar 15 19:38:22 2001 Delivered-To: freebsd-arch@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id 227C437B718; Thu, 15 Mar 2001 19:38:20 -0800 (PST) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.2/8.9.3) id f2G3cJs55363; Thu, 15 Mar 2001 19:38:19 -0800 (PST) (envelope-from dillon) Date: Thu, 15 Mar 2001 19:38:19 -0800 (PST) From: Matt Dillon Message-Id: <200103160338.f2G3cJs55363@earth.backplane.com> To: John Baldwin Cc: Matthew Jacob , arch@FreeBSD.org Subject: Re: Proposal for the CPU interrupt API References: Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :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