From owner-freebsd-current Thu Mar 7 14:49:48 2002 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 62D1737B423; Thu, 7 Mar 2002 14:49:07 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id g27Mn7f70164; Thu, 7 Mar 2002 14:49:07 -0800 (PST) (envelope-from dillon) Date: Thu, 7 Mar 2002 14:49:07 -0800 (PST) From: Matthew Dillon Message-Id: <200203072249.g27Mn7f70164@apollo.backplane.com> To: Robert Watson Cc: Warner Losh , Julian Elischer , "Justin T. Gibbs" , John Baldwin , Bruce Evans , Terry Lambert , Alfred Perlstein , Bosko Milekic , Seigo Tanimura , FreeBSD current users Subject: Re: Patch for critical_enter()/critical_exit() & interrupt assem References: Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG :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 Huh? I have made no API changes that have any effect whatsoever on these architectures. Jake is free to implement whatever he wants for them, all I intend to do is make it easier and more flexible to do so. Sure, I intend to move critical_enter() and critical_exit() from MI to MD, but all that means for non-i386 architectures is that the EXACT procedures for critical_enter() and critical_exit() now sitting in kern/kern_switch.c will be copied into //critical.c. That's the only effect for these other architectures. How our architectures handle things like deferred interrupts and SWI is architecture specific. It always has been and always will be. That doesn't mean we have to duplicate a large piece of code in //critical.c (for example, SWI handling or deferred context switch support), it simply means that these functions will be written in an MI section and the MD critical_*() functions will simply call the MI functions. This work will come to a grand total of 2 or 4 lines of code per architecture. Big fucking deal! -Matt Matthew Dillon :I don't pretend to understand all the issues here, but I think it's :important to recognize that there have been several coherrent responses to :the current patch that do need to be addressed. I think the preference :I've seen from a number of developers is that the be addressed before the :commit, rather than after. : :Robert N M Watson FreeBSD Core Team, TrustedBSD Project :robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message