Messages in this thread | | | From | Chris Metcalf <> | Subject | Re: [PATCH 1/7] atomic: Export fetch_or() | Date | Mon, 30 Nov 2015 13:17:14 -0500 |
| |
(Resending as plain text. Not sure what Thunderbird was smoking to make this message multipart/alternative originally...)
On 11/30/2015 12:36 PM, Frederic Weisbecker wrote: > On Tue, Nov 24, 2015 at 04:48:35PM -0500, Chris Metcalf wrote: >> >Unless you want to take a big diversion into atomics, I'd be tempted >> >to leave Peter's macro alone and just write it off as necessary evil >> >to handle the fact that thread_info.flags is all kinds of different sizes >> >and types on different platforms, and definitely never an atomic_t. >> >Instead just create an inline function atomic_return_or(), or >> >whatever name you prefer, that operates on an atomic_t, and use >> >the atomic_t type for your structure field. It's clearly a win to mark >> >the data types as being atomic to the extent we can do so, I think. > I agree that cmpxchg, test_and_set_bit, fetch_or... functions with loose > namespaces aren't the best layout. > > But casting thread_info to atomic_t really worries me, I'm not sure the ending > result would be correct at all. I prefer to sacrify correctness over namespace > sanity:-)
Just to clear, I wasn't suggesting that that necessarily was the way for you to go. The last four lines of my message quoted above are what I think might be the best way forward, and don't involve messing with thread_info at all.
-- Chris Metcalf, EZChip Semiconductor http://www.ezchip.com
| |