On Mon, Nov 12, 2018 at 7:11 AM, Hans Verkuil <hverkuil@xxxxxxxxx> wrote:
>>>>>> What would be a good improvement is if you add this to the kernel command options:
>>>>>> "vivid.n_devs=2 vivid.multiplanar=1,2"
>>>>>>
>>>>>> This will create two vivid instances, one using the single planar API and one using
>>>>>> the multiplanar API. That will improve the test coverage.
>>>>>
>>>>> Re this and collisions between multiple test processes. We actually
>>>>> would like to have moar devices and partition them between test
>>>>> processes. Say if we need need devices for 8 test processes, will it
>>>>> work to specify something like "vivid.n_devs=16
>>>>> vivid.multiplanar=1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2" and then use
>>>>> devices 0/1 in the first test process, 2/3 in the second and so on?
>>>>>
>>>>> Without giving any flags, I see 8 /dev/video* devices, does
>>>>> vivid.n_devs defaults to 8?
>>>>
>>>> I am a bit lost.
>>>>
>>>> vivid.n_devs=16 vivid.multiplanar=1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2
>>>> creates 32 /dev/video* devices.
>>>
>>> I see 38 /dev/video* devices: the first 3 are from vimc, then 2 * 16 = 32
>>> vivid devices (2 video nodes for each instance), then a vim2m device and
>>> finally two vicodec devices.
>>>
>>> So you should always see 6 + n_devs * 2 video devices.
>>>
>>>>
>>>> but vivid.n_devs=8 vivid.multiplanar=1,2,1,2,1,2,1,2 creates 24
>>>> /dev/video* devices.
>>>>
>>>> These parameters also affect /dev/{vbi,radio,swradio} in strange ways
>>>>
>>>> Also, by default there is /dev/radio0 and /dev/radio1, are these
>>>> different types of devices, e.g. "source" and "sink"? Or they are
>>>> identical? And the same question for other types of devices?
>>>
>>> vivid creates two radio devices per instance: one emulates a radio tuner,
>>> one emulates a radio modulator (so yes, source and sink). Same for vbi
>>> (one source, one sink) and one swradio device. It also creates two cec
>>> devices (source and sink).
>>>
>>>>
>>>> How can I create 8 independent partitions of devices? What devices
>>>> will belong to each partition?
>>>
>>> Exactly as you did above. Instance X (starting at 0) uses video nodes
>>> 3+2*X and 4+2*X.
>>
>> Thanks! Now I got it.
>> I've extended syzkaller to create more devices, use planar/non-planar,
>> radio, swradio, cec, vbi:
>>
>> https://github.com/google/syzkaller/commit/f3c4e6185953baea53d5651b84bd5897c02627f4#diff-a6fc2c4d3df5a6bcb42a628db614175f
>>
>> https://github.com/google/syzkaller/commit/f3c4e6185953baea53d5651b84bd5897c02627f4#diff-c60ec5d4add9b876f5d28fdeeaf3b7b8
>
> The cec devices do not use the V4L2 API, so it might be premature to add those.
It won't harm either. Fuzzer will still be able to call some
completely random stuff on them. It also serves as a reminded that
this is something we want to give to fuzzer, but don't have more
detailed descriptions.
> I plan on providing a patch for CEC in the near (?) future. Do you happen to
> have a script or something that can convert an API header to something that
> syzkaller needs? Or is it all manual?
It's manual at the moment.
We want to create some kind of helper thing that would at least
provide a skeleton. But in the end manual work is required anyway. For
example, there is an int field, is it just an int, or an fd, or some
set of flags, or something else? If there is a string, what are the
expected values? Etc. This information is simply not in the existing
kernel headers.
