Date: Thu, 7 Mar 2002 14:49:07 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: Robert Watson <rwatson@FreeBSD.ORG> Cc: Warner Losh <imp@harmony.village.org>, Julian Elischer <julian@elischer.org>, "Justin T. Gibbs" <gibbs@scsiguy.com>, John Baldwin <jhb@FreeBSD.ORG>, Bruce Evans <bde@zeta.org.au>, Terry Lambert <tlambert2@mindspring.com>, Alfred Perlstein <alfred@FreeBSD.ORG>, Bosko Milekic <bmilekic@unixdaemons.com>, Seigo Tanimura <tanimura@r.dl.itc.u-tokyo.ac.jp>, FreeBSD current users <current@FreeBSD.ORG> Subject: Re: Patch for critical_enter()/critical_exit() & interrupt assem Message-ID: <200203072249.g27Mn7f70164@apollo.backplane.com> References: <Pine.NEB.3.96L.1020307171254.23264D-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
: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 <arch>/<arch>/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
<arch>/<arch>/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
<dillon@backplane.com>
: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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200203072249.g27Mn7f70164>