removal of ipi_all() and ipi_self() [Re: cvs commit: src/sys/sparc64/include smp.h src/sys/sparc64/sparc64 genassym.c mp_machdep.c]

John Baldwin jhb at freebsd.org
Mon Sep 22 21:09:33 UTC 2008


On Saturday 20 September 2008 07:11:53 pm Marius Strobl wrote:
> On Thu, Sep 18, 2008 at 12:48:52PM -0700, Marcel Moolenaar wrote:
> > 
> > On Sep 18, 2008, at 12:19 PM, Marius Strobl wrote:
> > 
> > >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.
> > 
> > That's DS (=developer-specific) code rather than MI or MD code :-)
> > 
> > Sending a test IPI to 'self' helps with bring-up or porting, but
> > serves no real purpose (other than maybe a POST-like purpose)
> > once IPIs are known to work...
> > 
> 
> Okay, I take these as a call for removing ipi_all() and ipi_self()
> along with the ia64 and powerpc test IPI code completely. A patch
> doing just that and which passes a universe build just fine is at:
> http://people.freebsd.org/~marius/nuke_ipi_all_self.diff
> Does anybody object to committing it? Should __FreeBSD_version be
> bumped for this?

I think this is ok.

-- 
John Baldwin


More information about the freebsd-arch mailing list