Date: Thu, 7 Mar 2002 20:58:44 -0500 From: Jake Burkholder <jake@locore.ca> To: Robert Watson <rwatson@FreeBSD.ORG> Cc: Matthew Dillon <dillon@apollo.backplane.com>, FreeBSD current users <current@FreeBSD.ORG> Subject: Re: Patch for critical_enter()/critical_exit() & interrupt assem Message-ID: <20020307205844.C12044@locore.ca> In-Reply-To: <Pine.NEB.3.96L.1020307171254.23264D-100000@fledge.watson.org>; from rwatson@FreeBSD.ORG on Thu, Mar 07, 2002 at 05:21:21PM -0500 References: <200203072143.g27LhaL97112@harmony.village.org> <Pine.NEB.3.96L.1020307171254.23264D-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Apparently, On Thu, Mar 07, 2002 at 05:21:21PM -0500, Robert Watson said words to the effect of; > > On Thu, 7 Mar 2002, Warner Losh wrote: > > > In message <Pine.BSF.4.21.0203071334010.37321-100000@InterJet.elischer.org> Julian Elischer writes: > > : > > : > > : On Thu, 7 Mar 2002, Justin T. Gibbs wrote: > > : > > > : > Then do the right things so it will. > > : > > : Unfortunatly that has been proven to not work. > > : > > : after reverting the change and silently waiting for a week > > : 1/ no person bothered to review it. > > : 2/ people assumed the patch had gone away. > > > > Ummm, There are reviews in the archives that object to the API as it > > relates to optimization and those objections haven't been sanely > > answered with anything more constructive than "BS". > > The primary objections I've seen from Jake, and he posted them as part of > the earlier thread prior to the commit, was that the API changes proposed > by Matt don't make sense for the sparc64 implementation, uni-processor or > multi-processor, and that while these changes might be appropriate for > i386, he wanted to see the APIs set up in such a way that the differences > in architectures were hidden in the MD code. This suggests working some > more on the API before moving on, and my reading of earlier posts in the > thread from John was that that was what he had in mind also. Yes. What I would like and what I mentioned before is for this to be hidden behind cpu_critical_enter/exit. Specifically, cpu_critical_enter would be a null macro for i386, which would turn critical_enter into just an increment, as Matt wanted. cpu_critical_exit would do all the magic of unpending interrupts. The reason for this is that I would like to see critical_exit handled any pending preemptions for a thread. We do not yet know exactly how this will work so I would like this to be done in MI code to start with. The code must not make assumptions that are not valid on all platforms. This is easiest if they use the same code. This is not about duplication of code in several MD files. Bruce also had some comments which were shrugged off, I thought they were important. Specifically, please do not make unnecessary changes to the assembler code. Macros do not need to be defined before they are used, I believe this was the justification for some of the reordering in apic_vector.s which makes the patch confusing. Please do not tab out the "; \" at the end of the lines in the INTR and FAST_INTR macros in icu_vector.s. This just makes unnecessary diffs. The PUSH_DUMMY macro must push a reasonable eip value, in addition to the code segment, so that profiling and stack traces work right. If you have not already, please make sure that a trace from inside an interrupt handler that was unpended looks somewhat normal. Please also make sure that kgdb is able to decode the frame properly. It assumes that the eip of the frame will be near certain kernel symbols in order to determine what kind of frame it is. Jake To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020307205844.C12044>