Date: Thu, 18 Sep 2008 21:19:47 +0200 From: Marius Strobl <marius@alchemy.franken.de> To: John Baldwin <jhb@freebsd.org> Cc: cvs-src@freebsd.org, src-committers@freebsd.org, cvs-all@freebsd.org Subject: Re: cvs commit: src/sys/sparc64/include smp.h src/sys/sparc64/sparc64 genassym.c mp_machdep.c Message-ID: <20080918191947.GX94638@alchemy.franken.de> In-Reply-To: <200809181027.51997.jhb@freebsd.org> References: <200809181356.m8IDuaxT089888@repoman.freebsd.org> <200809181027.51997.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Sep 18, 2008 at 10:27:51AM -0400, John Baldwin wrote: > On Thursday 18 September 2008 09:56:30 am Marius Strobl wrote: > > marius 2008-09-18 13:56:30 UTC > > > > FreeBSD src repository > > > > Modified files: > > sys/sparc64/include smp.h > > sys/sparc64/sparc64 genassym.c mp_machdep.c > > Log: > > SVN rev 183142 on 2008-09-18 13:56:30Z by marius > > > > - Newer firmware versions no longer provide SUNW,stop-self so just > > disable interrupts and loop forever with these. > > - Hide all MP-related bits in <machine/smp.h> underneath #ifdef SMP. > > - Inline ipi_all_but_self(9) and ipi_selected(9). We don't expose any > > additional bits but save a few cycles by doing so. > > - Remove ipi_all(9), which actually only called panic(9). It can't be > > implemented natively anyway and having it removed at least causes > > MI users to fail already fail when linking. > > Should we just remove ipi_all() completely? > Well, grepping in the CVS repository shows that there never was an actually consumer of ipi_all() (only #ifdef'ed out ones in ironically the sparc64 code) so it seems to be a good candidate for axing. Generally I can't think of a reason why MI code would want a CPU to send an IPI to itself. Actually, ipi_self() also isn't and never was used in MI code, only in ia64 and powerpc code for testing purposes. Marius
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080918191947.GX94638>