Guennadi Liakhovetski wrote:
> On Tue, 17 May 2011, Sakari Ailus wrote:
>
>> Guennadi Liakhovetski wrote:
>
> [snip]
>
>>> I don't understand this. We do _not_ want to allow holes in indices. For
>>> now we decide to not implement DESTROY at all. In this case indices just
>>> increment contiguously.
>>>
>>> The next stage is to implement DESTROY, but only in strict reverse order -
>>> without holes and in the same ranges, as buffers have been CREATEd before.
>>> So, I really don't understand why we need arrays, sorry.
>>
>> Well, now that we're defining a second interface to make new buffer
>> objects, I just thought it should be made as future-proof as we can. But
>> even with single index, it's always possible to issue the ioctl more
>> than once and achieve the same result as if there was an array of indices.
>>
>> What would be the reason to disallow creating holes to index range? I
>> don't see much reason from application or implementation point of view,
>> as we're even being limited to such low numbers.
>
> I think, there are a few locations in V4L2, that assume, that for N number
> of buffers currently allocated, their indices are 0...N-1. Just look for
> loops like
>
> for (buffer = 0; buffer < q->num_buffers; ++buffer) {
>
> in videobuf2-core.c.
This code is in implementation of videobuf2, it's not the spec. We're
designing a new interface here and its behaviour musn't be restrained by
the current codebase. The videobuf2 must be changed to support the new
ioctls in any case; those functions must be fixed as the support for
CREATE_BUF and other new IOCTLs is added to videobuf2.
The above loop also likely assumes that the index of the first video
buffer to be allocated is zero; this would mean that no more than one
allocation of n buffers could be made, defeating the purpose of the new
interface.
Regards,
--
Sakari Ailus
sakari.ailus@xxxxxxxxxxxxxxxxxxxxxxxxxx
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
