Date: Thu, 10 Feb 2005 10:37:03 -0800
From: Nishanth Aravamudan <nacc@us.ibm.com>
To: David Brownell <david-b@pacbell.net>
Cc: greg@kroah.com, linux-kernel@vger.kernel.org,
       Al Borchers <alborchers@steinerpoint.com>
Subject: Re: [RFC PATCH] add wait_event_*_lock() functions
Message-ID: <20050210183703.GF2364@us.ibm.com>
References: <20050210173948.GE2364@us.ibm.com> <200502101021.58630.david-b@pacbell.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <200502101021.58630.david-b@pacbell.net>
User-Agent: Mutt/1.5.6+20040907i
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1415
Lines: 33

On Thu, Feb 10, 2005 at 10:21:58AM -0800, David Brownell wrote:
> On Thursday 10 February 2005 9:39 am, Nishanth Aravamudan wrote:
> > Hi David, LKML,
> > 
> > It came up on IRC that the wait_cond*() functions from
> > usb/serial/gadget.c could be useful in other parts of the kernel. Does
> > the following patch make sense towards this? 
> 
> I know that Al Borchers -- who wrote those -- did so with that
> specific notion.  And it certainly makes sense to me, in
> principle, that such primitives exist in the kernel ... maybe
> with some tweaks first.  (And docs for all the wait_* calls?)

I would be happy to document all the wait_* callers, especially when
which should be used, their correspondence to the other sleep-functions,
etc.

> But nobody's pressed the issue before, to the relevant audience:
> namely, LKML.  I'd be interested to hear what other folk think.
> Clearly these particular primitives don't understand how to cope
> with nested spinlocks, but those are worth avoiding anyway.

Yes, I was considering that issue, but I figured let's go for the simple
case now and that should be good enough for *most* cases.

Thanks for the feedback!

-Nish
-
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/