Messages in this thread | | | Date | Tue, 5 Jan 2010 16:34:45 -0600 (CST) | From | Christoph Lameter <> | Subject | Re: [RFC local_t removal V1 0/4] Remove local_t |
| |
On Tue, 5 Jan 2010, Mathieu Desnoyers wrote:
> Yes, removing the local_t type could make sense. However, local_t maps > to a volatile long, not just "long". Secondly, I am concerned about the > fact that the patch you propose:
Volatile is discouraged as far as I can tell.
> - does not create the primitives I use in lttng > - only deals with x8
As I said its an RFC. This provides all the functionality you need through. The rest is sugar coating.
> In lttng (which is out of tree, but widely used), I need the equivalent > of: > > local_read > local_set > local_add > local_cmpxchg > local_add_return > local_inc
Please read the patch! This is all provided. add_local_return in the RFC provides what is needed to replace local_add, local_inc. We can add these explicitly.
local_cmpxchg replacement is already in there in the form of cmpxchg_local().
> The approach of just doing the x86 implementation and leaving all the > other architectures "for later" with a slow/non atomic generic fallback > is, imho, a no-go, given that some people (myself, actually) already > took the time to go through all the kernel architectures to create the > optimized local.h headers. Basically, you are destroying all that work, > asking for it to be done all over again.
AS I said this is an RFC. I can easily generate all these things from the existing local.hs for the architectures.
> I therefore argue that we should keep local.h as-is as long as the > replacement lacks the wide architecture support and primitive variety > found in local.h.
Cool down and please review the patch.
| |