lkml.org 
[lkml]   [2002]   [Mar]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH] 2.5.1-pre5: per-cpu areas
Date
In message <p73bsdrsftu.fsf@oldwotan.suse.de> you write:
> Rusty Russell <rusty@rustcorp.com.au> writes:
>
> > In message <15504.7958.677592.908691@napali.hpl.hp.com> you write:
> > > OK, I see this. Unfortunately, HIDE_RELOC() causes me problems
> > > because it prevents me from taking the address of a per-CPU variable.
> > > This is useful when you have a per-CPU structure (e.g., cpu_info).
> > > Perhaps there should/could be a version of HIDE_RELOC() that doesn't
> > > dereference the resulting address?
> >
> > Yep, valid point. Patch below: please play.
>
> Please don't do that. I cannot easily take the address of a per CPU
> variable on x86-64, or rather only with additional overhead. If you need the
> address of one please use a different macro for that.

Sorry, I think one macro to get the address, one to get the contents
is a *horrible* interface. per_cpu() and per_cpu_ptr() or something?
I think you'll find that per_cpu_ptr would be fairly common, so we're
forced into a bad interface for little gain. You might be better off
using another method to implement per-cpu areas.

To be honest, it was merely my oversight that the statement expression
didn't allow the address to be taken in the first place, not a
feature.

Sorry,
Rusty.
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:25    [W:0.085 / U:0.684 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site