Compliance tests for new public API features

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Gustavo, Alexandre,

As you may have seen I have been extending the v4l2-compliance utility with tests
for v4l-subdevX and mediaX devices. In the process of doing that I promptly
found a bunch of bugs. Mostly little things that are easy to fix, but much
harder to find without proper tests.

You are both working on new API additions and I want to give a heads-up that
I want to have patches for v4l2-compliance that test the new additions to a
reasonable extent.

I say 'reasonable' because I suspect that e.g. in-fence support might be hard
to test. But out-fences can definitely be tested and for in-fences you can
at minimum test what happens when you give it an invalid file descriptor.

For the request API is it obviously too early to start writing tests, but
as the API crystallizes you may consider starting to work on it.

I've decided to be more strict about this based on my experiences. I'm more
than happy to assist and give advice, especially since this is a bit of a late
notice, particularly for Gustavo.

But every time we skip this step it bites us in the ass later on.

It is also highly recommended to add fence/request support to the vivid and
vim2m drivers. It makes it much easier to find regressions in the API due to
future changes since you don't need 'real' hardware for these drivers.

Again my apologies for the late notice, but it is better to make these tests
now while you are working on the new feature, rather than doing it much later
and finding all sorts of gremlins in the API.

Regards,

	Hans



[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux