Mathieu Desnoyers <mathieu.desnoy...@efficios.com> wrote: > * Eric Wong (normalper...@yhbt.net) wrote: > > /* > > + * __wfcq_append_local: append one local queue to another local queue > > + * > > + * No memory barriers are issued. Mutual exclusion is the responsibility > > + * of the caller. > > + * > > + * Returns false if the queue was empty prior to adding the node. > > + * Returns true otherwise. > > + */ > > +static inline bool __wfcq_append_local(struct wfcq_head *head, > > Following the rest of the header, we could use: > > ___wfcq_append() for this function,
OK. However, I think ___ is a little confusing (but I'm easily confused :x). I didn't even realize some functions in wfcqueue.h had ___ (vs __) until just now(!) But I will resend later tonight/tomorrow with ___ for consistency with the existing API unless I've convinced you "_local" is easier :) On a related note to underscores, I totally missed the existence of ____cacheline_aligned_in_smp in my first RFC even though I had seen the __ version for .data around. > and: > > __wfcq_enqueue() > > we should also update the "Synchronization table" at the beginning of > the file accordingly. Will update. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
