[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH v4 1/5] xen/ppc: Implement atomic.h
On 9/12/23 1:48 AM, Jan Beulich wrote: > On 12.09.2023 01:56, Shawn Anastasio wrote: >> On 9/11/23 6:33 AM, Jan Beulich wrote: >>> On 09.09.2023 00:50, Shawn Anastasio wrote: >>>> +static always_inline void read_atomic_size(const volatile void *p, void >>>> *res, >>>> + unsigned int size) >>>> +{ >>>> + ASSERT(IS_ALIGNED((vaddr_t)p, size)); >>>> + switch ( size ) >>>> + { >>>> + case 1: >>>> + *(uint8_t *)res = read_u8_atomic(p); >>>> + break; >>>> + case 2: >>>> + *(uint16_t *)res = read_u16_atomic(p); >>>> + break; >>>> + case 4: >>>> + *(uint32_t *)res = read_u32_atomic(p); >>>> + break; >>>> + case 8: >>>> + *(uint64_t *)res = read_u64_atomic(p); >>>> + break; >>>> + default: >>>> + __bad_atomic_read(p, res); >>>> + break; >>>> + } >>>> +} >>>> + >>>> +static always_inline void write_atomic_size(volatile void *p, const void >>>> *val, >>>> + unsigned int size) >>>> +{ >>>> + ASSERT(IS_ALIGNED((vaddr_t)p, size)); >>>> + switch ( size ) >>>> + { >>>> + case 1: >>>> + write_u8_atomic(p, *(const uint8_t *)val); >>>> + break; >>>> + case 2: >>>> + write_u16_atomic(p, *(const uint16_t *)val); >>>> + break; >>>> + case 4: >>>> + write_u32_atomic(p, *(const uint32_t *)val); >>>> + break; >>>> + case 8: >>>> + write_u64_atomic(p, *(const uint64_t *)val); >>>> + break; >>>> + default: >>>> + __bad_atomic_size(); >>>> + break; >>>> + } >>>> +} >>> >>> These two functions being as similar as is possible, ... >>> >>>> +#define read_atomic(p) >>>> \ >>>> + ({ >>>> \ >>>> + union { >>>> \ >>>> + typeof(*(p)) val; >>>> \ >>>> + char c[sizeof(*(p))]; >>>> \ >>>> + } x_; >>>> \ >>>> + read_atomic_size(p, x_.c, sizeof(*(p))); >>>> \ >>>> + x_.val; >>>> \ >>>> + }) >>> >>> ... is there a reason you keep using a union here ... >>> >>>> +#define write_atomic(p, x) >>>> \ >>>> + do >>>> \ >>>> + { >>>> \ >>>> + typeof(*(p)) x_ = (x); >>>> \ >>>> + write_atomic_size(p, &x_, sizeof(*(p))); >>>> \ >>>> + } while ( 0 ) >>> >>> ... while you did away with its use here? >>> >> >> Yes. In the case of read_atomic the caller is allowed (expected, even) >> to pass in const pointers for `p`, which wouldn't work if a simple >> typeof(*(p)) declaration was used since it would inherit the constness >> and thus wouldn't be passable to read_atomic_size. > > But the helper function's first parameter is const volatile void *, and > while you can't assign to a const variable, such a variable can of course > have an initializer (like you have it in the write case). > Yes, however the second parameter to read_atomic_size is a void *. If read_atomic macro's local `x_` was declared with a simple typeof(*(p)) then it would inherit the const and thus couldn't be passed as the second parameter to read_atomic_size. > Jan Thanks, Shawn
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |