lkml.org 
[lkml]   [2003]   [Sep]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH] kernel/futex.c: Uneeded memory barrier
Date
In message <20030914140839.GC16525@mail.jlokier.co.uk> you write:
> Rusty Russell wrote:
> > I personally *HATE* the set_task_state()/__set_task_state() macros.
> > Simple assignments shouldn't be hidden behind macros, unless there's
> > something really subtle involved.
>
> There _is_ something subtle involved. Back in ye olde days, folk

This is what I hate about EMail. You had two choices here: either I
don't understand you, or you don't understand me. You chose wrong,
and wasted a lot of time on an (excellent, BTW) explanation.

I wasn't clear: __set_task_state() and __set_current_state() should
not exist, they are assignments. set_task_state() should not exist,
since it's only used for current anyway. set_current_state should be
split into set_current_interruptible() and
set_current_uninterruptible(), except...

> Sprinkling special kinds of memory barrier into all the drivers is not
> the kind of thing driver writers get right. Also if you look at the

....hiding the subtlety in wrapper functions is the wrong approach. We
have excellent wait_event, wait_event_interruptible and
wait_event_interruptible_timeout macros in wait.h which these drivers
should be using, which would make them simpler, less buggy and
smaller.
Hope that clarifies?
Rusty.
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:48    [from the cache]
©2003-2011 Jasper Spaans