lkml.org 
[lkml]   [2010]   [Sep]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [patch 00/30] semaphore cleanup
Arnd,

On Tue, 7 Sep 2010, Arnd Bergmann wrote:

> On Tuesday 07 September 2010 17:38:33 Thomas Gleixner wrote:
> > Some of those can be converted to completions, but most of them have
> > utterly borked semantics. I'm not sure if its worth the trouble to
> > actually change all this as most of that stuff is ancient. Real
> > semaphores are not going away (at least not the counting type ones).
>
> Ok. I thought I had seen a series from Ingo some time ago that actually
> converted all of them to something else, but maybe I was mistaken.
>
> Not sure if there is anything to be gained (other than more work) from
> merging semaphore and rw_semaphore into a single implementation that
> is both counting and read-write.
>
> One problem I see (not with your series, just with semaphores in
> general) is that they keep creeping in through drivers/staging: About
> half the users we currently have are in staging. Obviously they get
> removed from there in order for drivers to graduate from staging, but
> not exposing the interface to device drivers would reduce the number
> of bad choices for authors to make.

sure, but most of them are really the init_MUTEX[_LOCKED] type which
has been copied over and over again for almost a decade.

That's going away, so people are actually forced to look into the
alternative solutions. And I do not worry too much about staging/*

Thanks,

tglx


\
 
 \ /
  Last update: 2010-09-07 22:25    [W:0.127 / U:0.708 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site