Re: [PATCH] V4L: Drop meaningless video_is_registered() call in v4l2_open()

[Hans Verkuil <hverkuil@xs4all.nl>]

On 09/09/2013 12:37 PM, Hans Verkuil wrote:
> On 09/09/2013 12:24 PM, Laurent Pinchart wrote:
>> Hi Hans,
>>
>> On Monday 09 September 2013 12:17:34 Hans Verkuil wrote:
>>> On 09/09/2013 12:10 PM, Laurent Pinchart wrote:
>>>> On Monday 09 September 2013 12:07:18 Hans Verkuil wrote:
>>>>> On 09/09/2013 12:00 PM, Laurent Pinchart wrote:
>>>>>> On Monday 09 September 2013 11:07:43 Hans Verkuil wrote:
>>>>>>> On 09/06/2013 12:33 AM, Sylwester Nawrocki wrote:
>>>>>> [snip]
>>>>>>
>>>>>>>> The main issue as I see it is that we need to track both driver
>>>>>>>> remove() and struct device .release() calls and free resources only
>>>>>>>> when last of them executes. Data structures which are referenced in
>>>>>>>> fops must not be freed in remove() and we cannot use dev_get_drvdata()
>>>>>>>> in fops, e.g. not protected with device_lock().
>>>>>>>
>>>>>>> You can do all that by returning 0 if probe() was partially successful
>>>>>>> (i.e. one or more, but not all, nodes were created successfully) by
>>>>>>> doing what I described above. I don't see another way that doesn't
>>>>>>> introduce a race condition.
>>>>>>
>>>>>> But isn't this just plain wrong ? If probing fails, I don't see how
>>>>>> returning success could be a good idea.
>>>>>
>>>>> Well, the nodes that are created are working fine. So it's partially OK
>>>>> :-)
>>>>>
>>>>> That said, yes it would be better if it could safely clean up and return
>>>>> an error. But it is better than returning an error and introducing a race
>>>>> condition.
>>>>>
>>>>>>> That doesn't mean that there isn't one, it's just that I don't know of
>>>>>>> a better way of doing this.
>>>>>>
>>>>>> We might need support from the device core.
>>>>>
>>>>> I do come back to my main question: has anyone actually experienced this
>>>>> error in a realistic scenario? Other than in very low-memory situations I
>>>>> cannot imagine this happening.
>>>>
>>>> What about running out of minors, which could very well happen with subdev
>>>> nodes in complex SoCs ?
>>>
>>> Is that really realistic? What's the worst-case SoC we have in terms of
>>> device nodes? Frankly, if this might happen then we should allow for more
>>> minors or make the minor allocation completely dynamic.
>>
>> For the 4 VSP1 instances on the R-Car H2, I need 33 video nodes and 65 (if I'm 
>> not mistaken) subdev nodes. That doesn't include the camera interface.
> 
> So that leaves 158 free minors. That's a lot of webcams that can be attached :-)

Just for the record: I would have no objection whatsoever if we increase
VIDEO_NUM_DEVICES to 512.

Regards,

	Hans