David --

> Question:  why do you have your own versions of the
> wait_event() macros?  (From <linux/sched.h> on 2.4,
> or <linux/wait.h> on 2.6 kernels.)

The macros are slighty different from linux/sched.h
(that is where I got them initially).  The difference
is that these macros expect that the caller has a
spin lock, which is held while testing the condition,
then dropped just before sleeping and reacquired just
after waking up and before retesting the condition.

This is a standard "condition variable" kind of synchronization
that is described in OS text books (sorry I don't have a reference
handy).

You need this construct to avoid race conditions where the condition
could change during or after the test.  For example

spin_lock(...);
x = a;
spin_unlock(...);
...
spin_lock(...);
y = b;
spin_unlock(...);
...
wait_event(...,x==0 && y==0,...);

This might return without x==0 && y==0, because the test x==0 && y==0
is done without holding the spin_lock, so the values of x and y could
change during or after the test.

What I want to know is that when the wait returns that x==0 && y==0
and that I have the lock so that the values cannot change on me until
I explicitly release the lock.  That is what my version of these macros
do.

I would like to add these macros to the kernel--I use them or
something similar frequently.  I was going to post to lkml about
it.  What do you think?

> It could at least go into my 2.4 and 2.6 BK trees, even
> if you don't yet submit it for the main kernel trees.
> Although as you say, it needs work yet -- seems like it
> may not be ready yet.

Yes, please make it part of your trees.  I will try to
integrate it into the 2.4 tree and send you a patch as
soon as I can.  2.6 will take a bit longer (I have only
started porting drivers to 2.6).  But if you or Greg get
to it first, that is great.

I would like to put it in the main kernel tree whenever
we think it is ready--I do want to test it some more.

> Did you maybe look at the arch/arm/mach-*/usb-char.c
> driver?  I don't know if any of that code would help
> much, now that you're well along with this "gadgetized"
> replacement; but maybe it'll have useful ideas.

Didn't know about this.  I will look at it.

-- Al



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Reply via email to