Re: [PATCH/RFC 1/4] V4L: add three new ioctl()s for multi-size videobuffer management

[Guennadi Liakhovetski <g.liakhovetski@gmx.de>]

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/