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.
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
