> It works for me.
Looking good.
> (I am still aware that there are some functions that fail that don't
> return values and some that do but aren't checked... one thing at a
> time. :) )
>
> John
>
> [1] I don't know that smp type locking is necessary since we only allow
> a single user at a time. I think I could be wrong on this, though. Is it
> possible for a process to open the camera and then fork giving us two
> users of the camera?
Fork() won't do this, clone() wil. Yes, you need full locking, where V4L
doesn't do it.l
> [2] Right now we destroy the proc interface in disconnect under the
> cam_lock. If we make the proc interface take the cam_lock for
> synchronization, then disconnect holds the lock, proc is waiting on it,
> and since the destroy_proc function was called, I can only assume that
> it will wait for the proc_read/write to finish which will never happen.
> I think that calling destroy_proc from disconnect before grabbing the
> cam_lock will solve this problem. If everyone agrees on that, then I'll
> submit another patch for it; I would like this one to go in first,
> though.
Nope, that's wrong. What do you do propose to let the read on proc
do if you run proc_destroy ?
> Also, I'm getting an error that the proc interface is unsafe and the
> module cannot be removed?
It is. Avoid proc if you can.
Regards
Oliver
-------------------------------------------------------
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
