Mailing List Archive: atrpms: devel

[PATCH] Fix building of uvc on 2.6.18-92

Index | Next | Previous | View Threaded

nixpanic at users

Jul 19, 2008, 3:29 AM

Post #1 of 11 (1123 views)
Permalink

[PATCH] Fix building of uvc on 2.6.18-92

It seems that uvc is not available for the latest RHEL/CentOS-kernels
yet. Building fails while Red Hat backported some USB-functions from
2.6.19 to 2.6.18-92.
The attached patch fixes this and was also sent to the
linux-uvc-devel-list for upstream inclusion, still waiting for a final
response.

Regards,
Niels de Vos

Attachments:

rhel-5.2.patch (0.67 KB)

Axel.Thimm at ATrpms

Jul 19, 2008, 2:16 PM

Post #2 of 11 (1080 views)
Permalink

Re: Fix building of uvc on 2.6.18-92 [In reply to]

Hi,

On Sat, Jul 19, 2008 at 12:29:43PM +0200, Niels de Vos wrote:
> It seems that uvc is not available for the latest RHEL/CentOS-kernels
> yet. Building fails while Red Hat backported some USB-functions from
> 2.6.19 to 2.6.18-92.

Yes, that's true!

> The attached patch fixes this and was also sent to the
> linux-uvc-devel-list for upstream inclusion, still waiting for a final
> response.

Thanks! The patch fails with the below output. That's on kernel
2.6.18-8.el5, I haven't tried o a RHEL5.2 kernel yet (mostly due to
the buildsystem ordering the builds that way). I wonder what makes
that kernel build fail - RHEL_RELEASE_CODE should not be set, so the
condition should not have tirggered (?).

Maybe RHEL_RELEASE_CODE is also set in userland? That would be bad. It
would force the check to be done differently :/

> Index: uvc_compat.h
> ===================================================================
> --- uvc_compat.h (revision 232)
> +++ uvc_compat.h (working copy)
> @@ -263,6 +263,9 @@
> *
> * Included in Linux 2.6.19
> */
> +
> +/* Red Hat Enterprise Linux 5.2 contains heavy backports, make an excepion */
> +#if !defined(RHEL_RELEASE_CODE) || RHEL_RELEASE_CODE < RHEL_RELEASE_VERSION(5,2)
> static inline int usb_endpoint_dir_in(const struct usb_endpoint_descriptor *epd)
> {
> return ((epd->bEndpointAddress & USB_ENDPOINT_DIR_MASK) == USB_DIR_IN);
> @@ -290,6 +293,7 @@
> {
> return (usb_endpoint_xfer_int(epd) && usb_endpoint_dir_in(epd));
> }
> +#endif /* RHEL_RELEASE_CODE */
>
> /*
> * USB auto suspend

CC [M] /builddir/uvc-r228/uvc_driver.o
In file included from /builddir/uvc-r228/uvcvideo.h:7,
from /builddir/uvc-r228/uvc_driver.c:40:
/builddir/uvc-r228/uvc_compat.h:264:76: error: missing binary operator before token "("
/builddir/uvc-r228/uvc_driver.c: In function 'uvc_parse_control':
/builddir/uvc-r228/uvc_driver.c:1139: error: implicit declaration of function 'usb_endpoint_is_int_in'
make[1]: *** [/builddir/uvc-r228/uvc_driver.o] Error 1
make: *** [_module_/builddir/uvc-r228] Error 2
make: Leaving directory `/srv/atrpms.net/atrpms/kernelsrc/el5-x86_64/2.6.18-8.el5-x86_64'
error: Bad exit status from /var/tmp/rpm-tmp.4978 (%build)

--
Axel.Thimm at ATrpms.net

nixpanic at users

Jul 19, 2008, 2:35 PM

Post #3 of 11 (1087 views)
Permalink

Re: Fix building of uvc on 2.6.18-92 [In reply to]

On Sat, Jul 19, 2008 at 11:16 PM, Axel Thimm <Axel.Thimm[at]atrpms.net> wrote:
> Hi,
>
> On Sat, Jul 19, 2008 at 12:29:43PM +0200, Niels de Vos wrote:
>> It seems that uvc is not available for the latest RHEL/CentOS-kernels
>> yet. Building fails while Red Hat backported some USB-functions from
>> 2.6.19 to 2.6.18-92.
>
> Yes, that's true!
>
>> The attached patch fixes this and was also sent to the
>> linux-uvc-devel-list for upstream inclusion, still waiting for a final
>> response.
>
> Thanks! The patch fails with the below output. That's on kernel
> 2.6.18-8.el5, I haven't tried o a RHEL5.2 kernel yet (mostly due to
> the buildsystem ordering the builds that way). I wonder what makes
> that kernel build fail - RHEL_RELEASE_CODE should not be set, so the
> condition should not have tirggered (?).

Hmm, I'll look into this and try to post an update.

> Maybe RHEL_RELEASE_CODE is also set in userland? That would be bad. It
> would force the check to be done differently :/

No, I think it is only set in include/linux/version.h.

>> Index: uvc_compat.h
>> ===================================================================
>> --- uvc_compat.h (revision 232)
>> +++ uvc_compat.h (working copy)
>> @@ -263,6 +263,9 @@
>> *
>> * Included in Linux 2.6.19
>> */
>> +
>> +/* Red Hat Enterprise Linux 5.2 contains heavy backports, make an excepion */
>> +#if !defined(RHEL_RELEASE_CODE) || RHEL_RELEASE_CODE < RHEL_RELEASE_VERSION(5,2)
>> static inline int usb_endpoint_dir_in(const struct usb_endpoint_descriptor *epd)
>> {
>> return ((epd->bEndpointAddress & USB_ENDPOINT_DIR_MASK) == USB_DIR_IN);
>> @@ -290,6 +293,7 @@
>> {
>> return (usb_endpoint_xfer_int(epd) && usb_endpoint_dir_in(epd));
>> }
>> +#endif /* RHEL_RELEASE_CODE */
>>
>> /*
>> * USB auto suspend
>
> CC [M] /builddir/uvc-r228/uvc_driver.o
> In file included from /builddir/uvc-r228/uvcvideo.h:7,
> from /builddir/uvc-r228/uvc_driver.c:40:
> /builddir/uvc-r228/uvc_compat.h:264:76: error: missing binary operator before token "("
> /builddir/uvc-r228/uvc_driver.c: In function 'uvc_parse_control':
> /builddir/uvc-r228/uvc_driver.c:1139: error: implicit declaration of function 'usb_endpoint_is_int_in'
> make[1]: *** [/builddir/uvc-r228/uvc_driver.o] Error 1
> make: *** [_module_/builddir/uvc-r228] Error 2
> make: Leaving directory `/srv/atrpms.net/atrpms/kernelsrc/el5-x86_64/2.6.18-8.el5-x86_64'
> error: Bad exit status from /var/tmp/rpm-tmp.4978 (%build)

I'll grep that kernel too and test with more versions.

Thanks, Niels

_______________________________________________
atrpms-devel mailing list
atrpms-devel[at]atrpms.net
http://lists.atrpms.net/mailman/listinfo/atrpms-devel

Axel.Thimm at ATrpms

Jul 19, 2008, 2:40 PM

Post #4 of 11 (1086 views)
Permalink

Re: Fix building of uvc on 2.6.18-92 [In reply to]

Hi,

On Sat, Jul 19, 2008 at 11:35:39PM +0200, Niels de Vos wrote:
> > Maybe RHEL_RELEASE_CODE is also set in userland? That would be bad. It
> > would force the check to be done differently :/
>
> No, I think it is only set in include/linux/version.h.

I found it under /usr/include/linux/version.h as
well. LINUX_VERSION_CODE is also being set, but the kernel Makefile
overrides it. The problem is that older RHEL5 kernels do not override
the RHEL* macros (I think). It all depends on whether
/usr/include/linux/version.h is being sourced in during the build.
--
Axel.Thimm at ATrpms.net

nixpanic at users

Jul 19, 2008, 3:03 PM

Post #5 of 11 (1089 views)
Permalink

Re: Fix building of uvc on 2.6.18-92 [In reply to]

Hi again :)

On Sat, Jul 19, 2008 at 11:40 PM, Axel Thimm <Axel.Thimm[at]atrpms.net> wrote:
> Hi,
>
> On Sat, Jul 19, 2008 at 11:35:39PM +0200, Niels de Vos wrote:
>> > Maybe RHEL_RELEASE_CODE is also set in userland? That would be bad. It
>> > would force the check to be done differently :/
>>
>> No, I think it is only set in include/linux/version.h.
>
> I found it under /usr/include/linux/version.h as
> well. LINUX_VERSION_CODE is also being set, but the kernel Makefile
> overrides it. The problem is that older RHEL5 kernels do not override
> the RHEL* macros (I think). It all depends on whether
> /usr/include/linux/version.h is being sourced in during the build.

But when compiling kernel modules, /usr/include/linuc/version.h should
not be included, correct?
Do you still want me to provide a patch for it?

Niels

_______________________________________________
atrpms-devel mailing list
atrpms-devel[at]atrpms.net
http://lists.atrpms.net/mailman/listinfo/atrpms-devel

Axel.Thimm at ATrpms

Jul 19, 2008, 3:07 PM

Post #6 of 11 (1082 views)
Permalink

Re: Fix building of uvc on 2.6.18-92 [In reply to]

Hi,

On Sun, Jul 20, 2008 at 12:03:20AM +0200, Niels de Vos wrote:
> On Sat, Jul 19, 2008 at 11:40 PM, Axel Thimm <Axel.Thimm[at]atrpms.net> wrote:
> > On Sat, Jul 19, 2008 at 11:35:39PM +0200, Niels de Vos wrote:
> >> > Maybe RHEL_RELEASE_CODE is also set in userland? That would be bad. It
> >> > would force the check to be done differently :/
> >>
> >> No, I think it is only set in include/linux/version.h.
> >
> > I found it under /usr/include/linux/version.h as
> > well. LINUX_VERSION_CODE is also being set, but the kernel Makefile
> > overrides it. The problem is that older RHEL5 kernels do not override
> > the RHEL* macros (I think). It all depends on whether
> > /usr/include/linux/version.h is being sourced in during the build.
>
> But when compiling kernel modules, /usr/include/linuc/version.h should
> not be included, correct?

Yes, but you never know what does include it and it isn't guarded. But
it's just a theory, I don't know whether it is actually included (but
I can't think of any other reason this failed).

> Do you still want me to provide a patch for it?

Of course! :)
--
Axel.Thimm at ATrpms.net

nixpanic at users

Jul 20, 2008, 8:38 AM

Post #7 of 11 (1082 views)
Permalink

Re: Fix building of uvc on 2.6.18-92 [In reply to]

Axel Thimm wrote:
> Hi,
>
> On Sun, Jul 20, 2008 at 12:03:20AM +0200, Niels de Vos wrote:
>> On Sat, Jul 19, 2008 at 11:40 PM, Axel Thimm <Axel.Thimm[at]atrpms.net> wrote:
>>> On Sat, Jul 19, 2008 at 11:35:39PM +0200, Niels de Vos wrote:
>>>>> Maybe RHEL_RELEASE_CODE is also set in userland? That would be bad. It
>>>>> would force the check to be done differently :/
>>>> No, I think it is only set in include/linux/version.h.
>>> I found it under /usr/include/linux/version.h as
>>> well. LINUX_VERSION_CODE is also being set, but the kernel Makefile
>>> overrides it. The problem is that older RHEL5 kernels do not override
>>> the RHEL* macros (I think). It all depends on whether
>>> /usr/include/linux/version.h is being sourced in during the build.
>> But when compiling kernel modules, /usr/include/linuc/version.h should
>> not be included, correct?
>
> Yes, but you never know what does include it and it isn't guarded. But
> it's just a theory, I don't know whether it is actually included (but
> I can't think of any other reason this failed).
>
>> Do you still want me to provide a patch for it?
>
> Of course! :)

Here it is, a patch against the current trunk (r232). Tested on
2.6.18-8.el5, 2.6.18-53.el5 and 2.6.18-92.1.6.el5.centos.plus. Seems
that 2.6.18-8.el5 does not have any RHEL_*-macros. This patch makes the
same check in 2-stages, fixing the use of an undefinde macro-function
(RHEL_RELEASE_VERSION). It should be safe to use on any other distro too.

Niels

Attachments:

compat_rhel52.patch (0.82 KB)

signature.asc (0.25 KB)

Axel.Thimm at ATrpms

Jul 20, 2008, 12:23 PM

Post #8 of 11 (1082 views)
Permalink

Re: Fix building of uvc on 2.6.18-92 [In reply to]

Hi,

On Sun, Jul 20, 2008 at 05:38:05PM +0200, Niels de Vos wrote:
> Here it is, a patch against the current trunk (r232). Tested on
> 2.6.18-8.el5, 2.6.18-53.el5 and 2.6.18-92.1.6.el5.centos.plus. Seems
> that 2.6.18-8.el5 does not have any RHEL_*-macros. This patch makes the
> same check in 2-stages, fixing the use of an undefinde macro-function
> (RHEL_RELEASE_VERSION). It should be safe to use on any other distro too.

thanks, that seems to work!

But I honestly don't understand why. :)

The same macros are being checked for existence and the "same"
conditions checked, what was the secret sauce? :)

> +/* Red Hat Enterprise Linux 5.2 contains heavy backports, make an excepion */
> +#ifdef RHEL_RELEASE_CODE
> +#if RHEL_RELEASE_CODE >= RHEL_RELEASE_VERSION(5,2)
> +/* we're on RHEL 5.2 or newer with backported usb_endpoint_*()-functions */
> +#define HAS_BACKPORTED_USB_EP
> +#endif
> +#endif
> +#ifndef HAS_BACKPORTED_USB_EP
> static inline int usb_endpoint_dir_in(const struct usb_endpoint_descriptor *epd)
> {
> return ((epd->bEndpointAddress & USB_ENDPOINT_DIR_MASK) == USB_DIR_IN);
> @@ -290,6 +299,7 @@
> {
> return (usb_endpoint_xfer_int(epd) && usb_endpoint_dir_in(epd));
> }
> +#endif /* !HAS_BACKPORTED_USB_EP */
>
> /*
> * USB auto suspend
--
Axel.Thimm at ATrpms.net

nixpanic at users

Jul 21, 2008, 2:52 AM

Post #9 of 11 (1066 views)
Permalink

Re: Fix building of uvc on 2.6.18-92 [In reply to]

On Sun, Jul 20, 2008 at 9:23 PM, Axel Thimm <Axel.Thimm[at]atrpms.net> wrote:
> Hi,
>
> On Sun, Jul 20, 2008 at 05:38:05PM +0200, Niels de Vos wrote:
>> Here it is, a patch against the current trunk (r232). Tested on
>> 2.6.18-8.el5, 2.6.18-53.el5 and 2.6.18-92.1.6.el5.centos.plus. Seems
>> that 2.6.18-8.el5 does not have any RHEL_*-macros. This patch makes the
>> same check in 2-stages, fixing the use of an undefinde macro-function
>> (RHEL_RELEASE_VERSION). It should be safe to use on any other distro too.
>
> thanks, that seems to work!
>
> But I honestly don't understand why. :)
>
> The same macros are being checked for existence and the "same"
> conditions checked, what was the secret sauce? :)

That's not complete clear to me either, heer is what I think...

First there was:
#if !defined(RHEL_RELEASE_CODE) || RHEL_RELEASE_CODE >=
RHEL_RELEASE_VERSION(5,2)

It seems that RHEL_RELEASE_VERSION() gets expanded, even if
RHEL_RELEASE_CODE is not defined.
Splitting the two checks like below, should not trigger the
RHEL_RELEASE_VERSION() as it is completely skipped.

For me it was some unexpected gcc/cpp behavior...

Cheers,
Niels

>> +/* Red Hat Enterprise Linux 5.2 contains heavy backports, make an excepion */
>> +#ifdef RHEL_RELEASE_CODE
>> +#if RHEL_RELEASE_CODE >= RHEL_RELEASE_VERSION(5,2)
>> +/* we're on RHEL 5.2 or newer with backported usb_endpoint_*()-functions */
>> +#define HAS_BACKPORTED_USB_EP
>> +#endif
>> +#endif
>> +#ifndef HAS_BACKPORTED_USB_EP
>> static inline int usb_endpoint_dir_in(const struct usb_endpoint_descriptor *epd)
>> {
>> return ((epd->bEndpointAddress & USB_ENDPOINT_DIR_MASK) == USB_DIR_IN);
>> @@ -290,6 +299,7 @@
>> {
>> return (usb_endpoint_xfer_int(epd) && usb_endpoint_dir_in(epd));
>> }
>> +#endif /* !HAS_BACKPORTED_USB_EP */
>>
>> /*
>> * USB auto suspend
> --
> Axel.Thimm at ATrpms.net
>

_______________________________________________
atrpms-devel mailing list
atrpms-devel[at]atrpms.net
http://lists.atrpms.net/mailman/listinfo/atrpms-devel

promac at gmail

Jul 21, 2008, 3:27 AM

Post #10 of 11 (1063 views)
Permalink

Re: Fix building of uvc on 2.6.18-92 [In reply to]

On Mon, Jul 21, 2008 at 6:52 AM, Niels de Vos <
nixpanic[at]users.sourceforge.net> wrote:

> On Sun, Jul 20, 2008 at 9:23 PM, Axel Thimm <Axel.Thimm[at]atrpms.net> wrote:
> > Hi,
> >
> > On Sun, Jul 20, 2008 at 05:38:05PM +0200, Niels de Vos wrote:
> >> Here it is, a patch against the current trunk (r232). Tested on
> >> 2.6.18-8.el5, 2.6.18-53.el5 and 2.6.18-92.1.6.el5.centos.plus. Seems
> >> that 2.6.18-8.el5 does not have any RHEL_*-macros. This patch makes the
> >> same check in 2-stages, fixing the use of an undefinde macro-function
> >> (RHEL_RELEASE_VERSION). It should be safe to use on any other distro
> too.
> >
> > thanks, that seems to work!
> >
> > But I honestly don't understand why. :)
> >
> > The same macros are being checked for existence and the "same"
> > conditions checked, what was the secret sauce? :)
>
> That's not complete clear to me either, heer is what I think...
>
> First there was:
> #if !defined(RHEL_RELEASE_CODE) || RHEL_RELEASE_CODE >=
> RHEL_RELEASE_VERSION(5,2)
>
> It seems that RHEL_RELEASE_VERSION() gets expanded, even if
> RHEL_RELEASE_CODE is not defined.
> Splitting the two checks like below, should not trigger the
> RHEL_RELEASE_VERSION() as it is completely skipped.
>
> For me it was some unexpected gcc/cpp behavior...
>
>

Remember that this code (#) is interpreted by the pre-compiler.
There is no way to guarantee how the tests are going to be evaluated.
It is really not advisable to use such a long construction, in this case.

--
Paulo Roma Cavalcanti
LCG - UFRJ

nixpanic at users

Jul 21, 2008, 7:25 AM

Post #11 of 11 (1066 views)
Permalink

Re: Fix building of uvc on 2.6.18-92 [In reply to]

On Mon, Jul 21, 2008 at 12:27 PM, Paulo Cavalcanti <promac[at]gmail.com> wrote:
>
>
> On Mon, Jul 21, 2008 at 6:52 AM, Niels de Vos
> <nixpanic[at]users.sourceforge.net> wrote:
>>
>> On Sun, Jul 20, 2008 at 9:23 PM, Axel Thimm <Axel.Thimm[at]atrpms.net> wrote:
>> > Hi,
>> >
>> > On Sun, Jul 20, 2008 at 05:38:05PM +0200, Niels de Vos wrote:
>> >> Here it is, a patch against the current trunk (r232). Tested on
>> >> 2.6.18-8.el5, 2.6.18-53.el5 and 2.6.18-92.1.6.el5.centos.plus. Seems
>> >> that 2.6.18-8.el5 does not have any RHEL_*-macros. This patch makes the
>> >> same check in 2-stages, fixing the use of an undefinde macro-function
>> >> (RHEL_RELEASE_VERSION). It should be safe to use on any other distro
>> >> too.
>> >
>> > thanks, that seems to work!
>> >
>> > But I honestly don't understand why. :)
>> >
>> > The same macros are being checked for existence and the "same"
>> > conditions checked, what was the secret sauce? :)
>>
>> That's not complete clear to me either, heer is what I think...
>>
>> First there was:
>> #if !defined(RHEL_RELEASE_CODE) || RHEL_RELEASE_CODE >=
>> RHEL_RELEASE_VERSION(5,2)
>>
>> It seems that RHEL_RELEASE_VERSION() gets expanded, even if
>> RHEL_RELEASE_CODE is not defined.
>> Splitting the two checks like below, should not trigger the
>> RHEL_RELEASE_VERSION() as it is completely skipped.
>>
>> For me it was some unexpected gcc/cpp behavior...
>>
>
>
> Remember that this code (#) is interpreted by the pre-compiler.
> There is no way to guarantee how the tests are going to be evaluated.
> It is really not advisable to use such a long construction, in this case.

Okay, thanks for the info :)
And as a side-note: this patch has just been included upstream (r233).

Niels

_______________________________________________
atrpms-devel mailing list
atrpms-devel[at]atrpms.net
http://lists.atrpms.net/mailman/listinfo/atrpms-devel

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact lists@gossamer-threads.com