Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 18 Sep 2008 12:48:52 -0700
From:      Marcel Moolenaar <xcllnt@mac.com>
To:        Marius Strobl <marius@alchemy.franken.de>
Cc:        cvs-src@freebsd.org, src-committers@freebsd.org, cvs-all@freebsd.org, John Baldwin <jhb@freebsd.org>
Subject:   Re: cvs commit: src/sys/sparc64/include smp.h src/sys/sparc64/sparc64 genassym.c mp_machdep.c
Message-ID:  <89B9A8BE-05F2-4DB2-B7B2-AB240AA9F0DD@mac.com>
In-Reply-To: <20080918191947.GX94638@alchemy.franken.de>
References:  <200809181356.m8IDuaxT089888@repoman.freebsd.org> <200809181027.51997.jhb@freebsd.org> <20080918191947.GX94638@alchemy.franken.de>

next in thread | previous in thread | raw e-mail | index | archive | help

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...

-- 
Marcel Moolenaar
xcllnt@mac.com






Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?89B9A8BE-05F2-4DB2-B7B2-AB240AA9F0DD>