[Linux-ia64] Re: [PATCH] sal calls w/o taking sal_lock

[Linux-ia64] Re: [PATCH] sal calls w/o taking sal_lock

[David Mosberger]

>>>>> On Tue, 1 Apr 2003 10:06:44 -0800, Jesse Barnes <jbarnes@sgi.com> said:

  Jesse> This patch adds SAL_CALL_NOLOCK so that platforms may call the SAL
  Jesse> without taking a lock, if appropriate.  The ia64_sal_mc_rendez() has
  Jesse> been changed to use it, since it won't return until all CPUs have been
  Jesse> rendevoused by the SAL, if I understand correctly.  It's also used by
  Jesse> various SN specific SAL routines that access the system controllers
  Jesse> and might be useful to other plaforms.

http://lia64.bkbits.net:8080/to-linus-2.5/cset@1.1113?nav=index.html

	--david

[Linux-ia64] Re: [PATCH] sal calls w/o taking sal_lock

[Jesse Barnes]

On Tue, Apr 01, 2003 at 12:28:26PM -0800, David Mosberger wrote:
>   Jesse> This patch adds SAL_CALL_NOLOCK so that platforms may call the SAL
>   Jesse> without taking a lock, if appropriate.  The ia64_sal_mc_rendez() has
>   Jesse> been changed to use it, since it won't return until all CPUs have been
>   Jesse> rendevoused by the SAL, if I understand correctly.  It's also used by
>   Jesse> various SN specific SAL routines that access the system controllers
>   Jesse> and might be useful to other plaforms.
> 
> http://lia64.bkbits.net:8080/to-linus-2.5/cset@1.1113?nav=index.html

Oops!  That's what I get for not checking bkbits before I post
something...  Anyway, glad it's there.

Thanks,
Jesse

Re: [Linux-ia64] Re: [PATCH] sal calls w/o taking sal_lock

[Keith Owens]

On Tue, 1 Apr 2003 12:28:26 -0800, 
David Mosberger <davidm@napali.hpl.hp.com> wrote:
>>>>>> On Tue, 1 Apr 2003 10:06:44 -0800, Jesse Barnes <jbarnes@sgi.com> said:
>
>  Jesse> This patch adds SAL_CALL_NOLOCK so that platforms may call the SAL
>  Jesse> without taking a lock, if appropriate.  The ia64_sal_mc_rendez() has
>  Jesse> been changed to use it, since it won't return until all CPUs have been
>  Jesse> rendevoused by the SAL, if I understand correctly.  It's also used by
>  Jesse> various SN specific SAL routines that access the system controllers
>  Jesse> and might be useful to other plaforms.
>
>http://lia64.bkbits.net:8080/to-linus-2.5/cset@1.1113?nav=index.html

I do not understand why you renamed the variables.  The SAL code is
enclosed in do { } while();  All variables within {} are local, they do
not need unique names.

RE: [Linux-ia64] Re: [PATCH] sal calls w/o taking sal_lock

[Van Maren, Kevin]

> I do not understand why you renamed the variables.  The SAL code is
> enclosed in do { } while();  All variables within {} are 
> local, they do not need unique names.

What happens to this:

#define foo(arg) do { int flag; arg = flag; } while (0)

If I do this:

	foo(flag);

Answer:

	do { int flag; flag = flag; } while (0);

Does his change make more sense now?

Kevin

Re: [Linux-ia64] Re: [PATCH] sal calls w/o taking sal_lock

[Keith Owens]

On Wed, 2 Apr 2003 00:09:53 -0600 , 
"Van Maren, Kevin" <kevin.vanmaren@unisys.com> wrote:
>> I do not understand why you renamed the variables.  The SAL code is
>> enclosed in do { } while();  All variables within {} are 
>> local, they do not need unique names.
>
>What happens to this:
>
>#define foo(arg) do { int flag; arg = flag; } while (0)
>
>If I do this:
>
>	foo(flag);
>
>Answer:
>
>	do { int flag; flag = flag; } while (0);
>
>Does his change make more sense now?

You get around that by using __flags in the macro.  You do not need
__ia64_sc_flags in SAL_CALL() and a different __ia64_scn_flags in
SAL_CALL_NOLOCK().  The old SAL_CALL() code has been there since IA64
was released and has never had any problems with name scopes.

Re: [Linux-ia64] Re: [PATCH] sal calls w/o taking sal_lock

[Andreas Schwab]

Keith Owens <kaos@ocs.com.au> writes:

|> I do not understand why you renamed the variables.  The SAL code is
|> enclosed in do { } while();  All variables within {} are local, they do
|> not need unique names.

Now consider what happens when you have a reference to a variable named
flags or fr in one of the macro arguments.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."