Re: [ANNOUNCE] git tree repositories & libv4l

[Hans de Goede <hdegoede@redhat.com>]

Hi,

On 02/24/2010 03:32 PM, Brandon Philips wrote:
> On 13:55 Wed 24 Feb 2010, Hans de Goede wrote:

<snip>
>> Where necessary libv4l currently has code snippets like:
>>
>> #ifndef V4L2_PIX_FMT_SPCA501
>> #define V4L2_PIX_FMT_SPCA501 v4l2_fourcc('S','5','0','1') /* YUYV per line */
>> #endif
>
> I don't think this is less work than copying the header file from the
> Kernel. Test building under all versions of the Kernel headers that
> exist to make sure something isn't missed isn't possible. It really is
> easier just to sync the header file up.
>
>> The reason for this is that I want to avoid carrying a copy of a dir
>> from some other tree, with all getting stale and needing sync all
>> the time issues that come with that, not to mention chicken and egg
>> problems in the case of new formats which simultaneously need to be
>> added to both libv4l and the kernel.
>
> Worst case is that if it is stale then it won't build since it depends
> on fancy new feature XYZ. But, at least it won't build on all systems
> instead of randomly breaking based on installed kernel headers
> version.
>
>> For example often I add support for V4L2_PIX_FMT_NEW_FOO to libv4l, before it
>> hits any official v4l-dvb kernel tree, with the:
>
> Please don't add features to releases before they are merged with
> Linus. It would suck to ship a copy of libv4l that has a different
> idea of structs or constants then the upstream Kernel.
>

Note the only thing added is a V4L2_PIX_FMT_xxx define, IOW this makes libv4l
recognize (and convert from) a new video format, which is to be generated
by a going upstream soon driver. With older kernels this won't make any
difference as those don't generate that format.

>> Approach this works fine, if I were to carry an include tree copy, that would
>> now need to become a patched include tree copy, and with the next sync I then
>> need to ensure that any needed patches are either already in the sync source,
>> or applied again.
>
> Or just fix it upstream with #ifdef __KERNEL__ tags once and for all,
> right?

I wasn't even talking about #ifdef __KERNEL__ issues, although yes those
exist too.

Regards,

Hans