Re: [RFC PATCH 0/3] Refactoring Videobuf2 for common use

[Junghak Sung <jh1009.sung@samsung.com>]

On 06/09/2015 02:39 AM, Mauro Carvalho Chehab wrote:
> Em Mon, 08 Jun 2015 16:42:48 +0200
> Hans Verkuil <hverkuil@xs4all.nl> escreveu:
>
>> On 06/08/2015 03:35 PM, Junghak Sung wrote:
>>> Hello everybody,
>>>
>>> This patch series refactories exsiting Videobuf2, so that not only V4L2
>>> but also other frameworks can use it to manage buffer and utilize
>>> queue.
>>>
>>> I would separate existing Videobuf2-core framework into two parts - common
>>> and v4l2-specific part. This work is as follows :
>>>
>>> 1. Separate existing vb2_buffer structure into common buffer and
>>>     v4l2-specific parts by removing v4l2-specific members and
>>>     embedding it into vb2_v4l2_buffer structure like this:
>>>
>>>      struct vb2_v4l2_buffer {
>>>          struct vb2_buffer    vb2;
>>>          struct v4l2_buffer   v4l2_buf;
>>>          struct v4l2_plane    v4l2_planes[VIDEO_MAX_PLANES];
>>>      };
>>>
>>> 2. Abstract the v4l2-specific elements, and specify them when the device
>>>     drives use them. For example, vb2_v4l2_buffer structure can be abstracted
>>>     by vb2_buffer structure, and device drivers can get framework-specific
>>>     object such as vb2_v4l2_buffer by using container_of().
>>>
>>> 3. Separate VB2-core framework into real VB2-core and v4l2-specific part.
>>>     This means that it moves V4L2-specific parts of VB2-core to v4l2-specific
>>>     part because current VB2-core framework has some codes dependent of V4L2.
>>>     As a result, we will have two VB2 files - videobuf2-core.c and
>>>     videobuf2-v4l2.c.
>>>
>>> Why do we try to make the VB2 framework to be common?
>>>
>>> As you may know, current DVB framework uses ringbuffer mechanism to demux
>>> MPEG-2 TS data and pass it to userspace. However, this mechanism requires
>>> extra memory copy because DVB framework provides only read() system call for
>>> application - read() system call copies the kernel data to user-space buffer.
>>>
>>> So if we can use VB2 framework which supports streaming I/O and buffer
>>> sharing mechanism, then we could enhance existing DVB framework by removing
>>> the extra memory copy - with VB2 framework, application can access the kernel
>>> data directly through mmap system call.
>>>
>>> This patch series is the first step for it.
>>>
>>> We have a plan for this work as follows:
>>>
>>> 1. Separate existing VB2 framework into three parts - VB2 common, VB2-v4l2,
>>>     and VB2-dvb. Of course, this change should not affect other v4l2-based
>>>     device drivers. This patch series includes some parts of this step.
>>>
>>> 2. Add new APIs for DVB streaming I/O. These APIs will be implemented
>>>     in VB2-dvb framework. So, we can remove unnecessary memory copy between
>>>     kernel-space and user-space by using these new APIs.
>>>     However, we leaves legacy interfaces as-is for backward compatibility.
>>>
>>> We are working on this project with Mauro and have a discussion with him
>>> on IRC channel weekly. Nowaday, we are discussing more detailed DVB user
>>> scenario for streaming I/O.
>>>
>>> The final goal of this project is to enhance current DVB framework.
>>> The first mission is to achieve zero-copy functionality between kernel-space
>>> and user-space with mmap system call. More missions are under consideration:
>>> i.e., we could share the buffer not only between kernel-space and user-space
>>> but also between devices - demux, hw video codec - by exporting a buffer
>>> to dmabuf fd with VB2 framework.
>>>
>>> Any suggestions and comments are welcome.
>>>
>>> Best regards,
>>> Junghak
>>>
>>> Junghak Sung (3):
>>>    modify the vb2_buffer structure for common video buffer     and make
>>>      struct vb2_v4l2_buffer
>>>    move struct vb2_queue to common and apply the changes related with
>>>      that     Signed-off-by: Junghak Sung <jh1009.sung@samsung.com>
>>>    make vb2-core part with not v4l2-specific elements
>> Patch 2/3 didn't arrive at linux-media for some reason. Can you post it again?
> Probably, the patch is too big. Vger doesn't accept patches bigger than
> a few hundreds of KB. Not sure what's the current limit.
>
> Junghak added the patches on his tree too:
> 	http://git.linuxtv.org/cgit.cgi/jsung/dvb-vb2.git/log/?h=dvb-vb2
>
> Junghak,
>
> You may try to play with the git options that improve rename/copy files,
> like:
> 	--find-copies-harder
> 	-M
> 	-C
>
> The last two options accepts a percentage parameter, like:
>    -C60	for detect changes that keep up to 60% of the original content.
>
> and:
> 	--diff-algorithm=minimal
> 	--diff-algorithm=patience
>
> Maybe with those options, the email produced by git format-patch will
> be small enough to fit at the VGER mailing list limits.
>
> If none of those work, please let us know.
I tried to reduce the size of patch 2/3 with the combinations of git 
options you recommended like :
     --minimal, --patience, -M[n], -C[n], --find-copies-harder
I found the patch 3/3 can be optimized with those options.
But, failed to optimize patch 2/3.
Is there any other solutions?

Regards,
Junghak
> Regards,
> Mauro
>   
>
>> Thanks!
>>
>> 	Hans
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>