On Monday 04 April 2011 09:55:17 Guennadi Liakhovetski wrote:
> On Sun, 3 Apr 2011, Pawel Osciak wrote:
> > On Fri, Apr 1, 2011 at 07:06, Guennadi Liakhovetski wrote:
> > > This patch extends the videobuf2 framework with new helper functions
> > > and modifies existing ones to support multi-size video-buffers.
[snip]
> > > diff --git a/drivers/media/video/videobuf2-core.c
> > > b/drivers/media/video/videobuf2-core.c index 71734a4..20e1572 100644
> > > --- a/drivers/media/video/videobuf2-core.c
> > > +++ b/drivers/media/video/videobuf2-core.c
[snip]
> > > @@ -241,16 +250,36 @@ static void __vb2_queue_free(struct vb2_queue *q)
> > > }
> > >
> > > /* Release video buffer memory */
> > > - __vb2_free_mem(q);
> > > + __vb2_free_mem(q, span);
> > >
> > > /* Free videobuf buffers */
> > > - for (buffer = 0; buffer < q->num_buffers; ++buffer) {
> > > + for (buffer = span->index;
> > > + buffer < span->index + span->count; ++buffer) {
> > > kfree(q->bufs[buffer]);
> > > q->bufs[buffer] = NULL;
> > > }
> > >
> > > - q->num_buffers = 0;
> > > - q->memory = 0;
> > > + q->num_buffers -= span->count;
> > > + if (!q->num_buffers)
> > > + q->memory = 0;
> > > +
> > > + return 0;
> > > +}
> > > +EXPORT_SYMBOL_GPL(vb2_destroy_bufs);
> > > +
> >
> > This messes up q->num_buffers, which is used in other places as the
> > upper bound for indexes and assumes <0; q->num_buffers> is contiguous.
> > Examples include querybufs, buffers_in_use. In general, I find it
> > unnecessary complicated and dangerous to allow introducing "holes" in
> > buffer indexes.
>
> Yes, there are issues... I think, we can just return -EBUSY on such
> fragmenting DESTROY calls. Anything left over will be freed on last
> close() anyway. Let's decide how we want to handle these and I'll prepare
> a v2, probably with documentation this time:-)
I also feel a bit uneasy about introducing holes in buffer indexes. Do we have
use cases for that right now ?
--
Regards,
Laurent Pinchart
--
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
