[KJ] Re: [PATCH] 18/34: ieee1394/video1394: replace

[Nishanth Aravamudan <nacc@us.ibm.com>]

[-- Attachment #1: Type: text/plain, Size: 1459 bytes --]

On Mon, Feb 14, 2005 at 08:34:20PM -0500, Jody McIntyre wrote:
> On Mon, Feb 14, 2005 at 04:50:47PM -0800, Nishanth Aravamudan wrote:
> 
> > > In my copy, it _unlocks_ around the sleep.  I don't see why this
> > > couldn't be done with wait_event_interruptible (unlock, wait, lock).
> > > Can you produce a patch with that?  I'll find a video1394 user to test
> > > it.
> > 
> > Sorry for my mis-statement/lack of clarity. In my copy, it also unlocks
> > around the sleep... The problem is that wait_event*() should be used in
> > such a way that the while-loop is not at all necessary (ideally).
> > Instead, we'll have a while-loop around the unlock-wait_event-lock code,
> > which is just ugly to me, as wait_event is just a macro around another
> > while loop. The real solution is wait_event_interruptible_lock().
> > Hopefully I can get such a macro accepted into mainline sooner or
> > later...
> 
> So you want to leave tho old code in until then?  Fair enough.
> 
> > I'm assuming the locking is done this way so that other variables protected by
> > the same lock can be changed while this one sleeps?
> 
> Correct.  See, for example, wakeup_dma_ir_ctx() .

I am not sure if you have seen some of the discussion (under the
subject: "[RFC UPDATE PATCH] add wait_event_*_lock() functions and
comments") on LKML regarding these macros. Does Arnd's proposal to fix
video1394 seem reasonable? I can throw up a patch, if you'd like to
test.

Thanks,
Nish

[-- Attachment #2: Type: text/plain, Size: 167 bytes --]

_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
http://lists.osdl.org/mailman/listinfo/kernel-janitors