Re: [Xenomai-core] [RFC][PATCH] shirq locking rework

[Jan Kiszka <jan.kiszka@domain.hid>]

[-- Attachment #1: Type: text/plain, Size: 1415 bytes --]

Philippe Gerum wrote:
> On Thu, 2007-06-21 at 13:05 +0200, Jan Kiszka wrote:
>> Jan Kiszka wrote:
>>> Well, and I wonder what this xnarch_memory_barrier() at each handler
>>> entry is for. Seems to be there for ages, don't see why right now.
> 
> AFAICT, this probably dates back to Xenomai 1.x, when we used to have a
> threaded interrupt model. The actual code looked like as follows, and
> the barrier was likely here to make sure that any change to the
> interrupt hit counter was visible from any other CPU which would run the
> interrupt service thread. The funny thing is that we did not have SMP
> support at that time, anyway...
> 
> static void xnintr_irq_handler (unsigned irq, void *cookie)
> 
> {
>     xnintr_t *intr = (xnintr_t *)cookie;
>     int s = XN_ISR_SCHED_T;
> 
>     intr->hits++;
> 
>     xnarch_memory_barrier();
> 
> 
> In short, I don't see any reason to keep this membar.

Fascinating: So many people came along this place, but no one dared to
touch it. :)

> 
>>  (The
>>> kernel has a golden rule for this: no barrier without comments!)
> 
> Yeah, right. It looks like the kernel has a slew of very official golden
> rules it basically does not care one dime to enforce in practice.
> Looking at the code, commenting membars is surely one of them...
> 

I saw Andrew Morton being strictly after uncommented ones in new code at
least.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]