From owner-freebsd-arch Fri Mar 16 16: 1:49 2001 Delivered-To: freebsd-arch@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 9A19B37B719; Fri, 16 Mar 2001 16:01:46 -0800 (PST) (envelope-from mjacob@feral.com) Received: from zeppo.feral.com (IDENT:mjacob@zeppo [192.67.166.71]) by feral.com (8.9.3/8.9.3) with ESMTP id QAA24973; Fri, 16 Mar 2001 16:01:45 -0800 Date: Fri, 16 Mar 2001 16:01:41 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: Terry Lambert Cc: John Baldwin , arch@FreeBSD.ORG Subject: Re: man pages In-Reply-To: <200103162351.QAA19187@usr07.primenet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > [ ... ] > > > Let's assume we have a broadcast interrupt platform, but disable_intr only > > disables interrupt recognition for the calling CPU. One might say it's a > > useless function- I'd say not. You *still* use locks to keep threads on other > > cpus out of critical regions- but you may have wanted to make sure you > > wouldn't be getting any ithreads pending on the *calling* cpu- I'm sure jhb > > can think of a number of cases this would help. > > Sounds like you want something like these: > > intr_disable_this_cpu() > ithread_diable_this_cpu() > ... > > It seems to me that the function ou are documenting is machine > specific, and should be named for the architecture/CPU/etc. to > which it applies. Umm..., no, disable_intr *could* be a global block. Perhaps I didn't pick the best example. It still remains that disable_intr disables interrupts. restore_intr restores the state that existed prior to the disable_intr call. The only thing which I think people have problems with is my running around saying "do *not* say whether it's global or cpu-local". > > In order to address some other folks' expressed concerns that this might be > > 'useless', some very careful wording has to occur. I don't think we want to > > say anything at all about using this as a synchronization mechanism, unless to > > say "Do *not* consider this to be a method for synchronization" > > I'd even say: > > Do *not* consider this to be a method for synchronization > Do *not* invert inter-cpu lock ordering after calling this > function, as it may result in a starvation deadlock Well, yes, sure. Isn't that kernel SMP 101? > Personally, I thinkit's useless to name a function after something which > it does, rather than naming it after something which you want it to do. > The distinction is subtle, I grant you, but people will be wanting to use > it for what it does _in order to get a resulting desirable effect_. If it > isn't cross-platform, it isn't cross platform. I'm having trouble following this. Let me try and reiterate (putting on my Solaris DDI/DKI team hat, FWIBWBN) that disable_intr/restore_intr would be required to be on all platforms, but might have subtly different meanings. > > I don't think it's reasonable to require an English degree or a Juris > Doctorate or both to be able to tell why you would want to call a function > with a name that seems to imply an incorrect usage might be reasonable and > safely used cross-platform. Jeez. I'm sorry, Terry. I'm not following this at all. -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message