On Mon, 26 May 2008 18:01:54 -0400
Alan Cox <alan@redhat.com> wrote:
Agreed.
Hmm... it maybe an interesting interim solution to create such function, and
moving the drivers to it.
What if we create 3 functions:
video_ioctl2_bkl()
video_ioctl2_serialized()
video_ioctl2_unlocked()
The first patch will point .ioctl_unlock to video_ioctl2_bkl.
A next step would be to move the drivers to use the serialized one. I suspect
that this will work properly on all devices that are using video_ioctl2, if
the videobuf locks are now 100% ok. So, it is just a matter of doing some stress
tests. We may start with vivi, since we have a complete domain on what this
driver is doing (e.g. no hardware surprises).
After having all those drivers using the _serialized() one, we can remove the bkl.
Then, we can focus on properly fixing the locks inside the drivers, and moving
one by one to video_ioctl2_unlocked.
IMO, we need to create a multi-thread stress userspace tool for checking the
locks at the ioctls. There are a few testing utils at mercurial tree, under
v4l2-apps/test. This can be a starting point for this tool. Also, Brandon
improved one of those tools to work with multithread.
What do you think?
Cheers,
Mauro
--