Hi, I noticed that include/xen/sched.h uses _atomic_*() in a couple
places, while all other Xen code uses atomic_*(). In general I think
functions prefixed with an underscore are not part of the public
interface...
This patch should be safe since atomic_*() just use volatile and
_atomic_*() do not.
Side note: the Xen copy of atomic.h appears to be a little out of date
with respect to the Linux 2.6.11 version, in which _atomic_*() is no
longer present (only atomic_*() are).
--- xen/include/xen/sched.h.old Thu Mar 10 16:01:14 2005
+++ xen/include/xen/sched.h Thu Mar 10 16:01:17 2005
@@ -194,12 +194,12 @@ static always_inline int get_domain(stru
do
{
old = seen;
- if ( unlikely(_atomic_read(old) & DOMAIN_DESTRUCTED) )
+ if ( unlikely(atomic_read(old) & DOMAIN_DESTRUCTED) )
return 0;
- _atomic_set(new, _atomic_read(old) + 1);
+ atomic_set(new, atomic_read(old) + 1);
seen = atomic_compareandswap(old, new, &d->refcnt);
}
- while ( unlikely(_atomic_read(seen) != _atomic_read(old)) );
+ while ( unlikely(atomic_read(seen) != atomic_read(old)) );
return 1;
}
Signed-off-by: Hollis Blanchard <hollisb@us.ibm.com>
--
Hollis Blanchard
IBM Linux Technology Center
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel
On 11 Mar 2005, at 14:57, Hollis Blanchard wrote:> Hi, I noticed that include/xen/sched.h uses _atomic_*() in a couple > places, while all other Xen code uses atomic_*(). In general I think > functions prefixed with an underscore are not part of the public > interface... > > This patch should be safe since atomic_*() just use volatile and > _atomic_*() do not. > > Side note: the Xen copy of atomic.h appears to be a little out of date > with respect to the Linux 2.6.11 version, in which _atomic_*() is no > longer present (only atomic_*() are).The xen _atomic_* functions aren''t like the old Linux ones -- they don''t take a pointer to the atomic_t. We use this in the scheduler to produce better-quality code. The patch you sent won''t compile because e.g., atomic_set and _atomic_set take different type parameters. -- Keir ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
On Mar 11, 2005, at 10:53 AM, Keir Fraser wrote:> > On 11 Mar 2005, at 14:57, Hollis Blanchard wrote: > >> Hi, I noticed that include/xen/sched.h uses _atomic_*() in a couple >> places, while all other Xen code uses atomic_*(). In general I think >> functions prefixed with an underscore are not part of the public >> interface... >> >> This patch should be safe since atomic_*() just use volatile and >> _atomic_*() do not. >> >> Side note: the Xen copy of atomic.h appears to be a little out of >> date with respect to the Linux 2.6.11 version, in which _atomic_*() >> is no longer present (only atomic_*() are). > > The xen _atomic_* functions aren''t like the old Linux ones -- they > don''t take a pointer to the atomic_t. We use this in the scheduler to > produce better-quality code. The patch you sent won''t compile because > e.g., atomic_set and _atomic_set take different type parameters.Ahh... I assumed asm-x86/atomic.h was simply out of date, but I see now that you''ve modified it yourself. So _atomic_* should now be considered part of the arch->common interface? Further, it should actually *not* be an atomic access at all? Of course it will be faster ("better-quality") code if it''s not assumed to be an atomic access... in which case isn''t the naming a little misleading? I noticed this problem because linux/include/asm-ppc64/atomic.h doesn''t have _atomic_* functions. I guess this means I will need to implement my own non-atomic _atomic_* functions? -- Hollis Blanchard IBM Linux Technology Center ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
On 11 Mar 2005, at 16:52, Hollis Blanchard wrote:> Ahh... I assumed asm-x86/atomic.h was simply out of date, but I see > now that you''ve modified it yourself. So _atomic_* should now be > considered part of the arch->common interface? Further, it should > actually *not* be an atomic access at all? Of course it will be faster > ("better-quality") code if it''s not assumed to be an atomic access... > in which case isn''t the naming a little misleading? > > I noticed this problem because linux/include/asm-ppc64/atomic.h > doesn''t have _atomic_* functions. I guess this means I will need to > implement my own non-atomic _atomic_* functions?We only define single-word get/set macros (_atomic_read/_atomic_set). These are trivially atomic on any architecture we care about. In fact we only use them to set up local variables prior to pushing out to a shared atomic variable, so the atomicity doesn''t really matter to us; it''s a bonus. -- Keir ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel