new_build on ubuntu (dvbdev.c)

new_build on ubuntu (dvbdev.c)

[Vincent McIntyre]

Hi,
I'm trying to build on 2.6.32 (ubuntu lucid i386).

I followed the instructions for building from git[1]
but I get an error I don't understand.

make -C /lib/modules/2.6.32-25-3dbc39-generic/build
SUBDIRS=/home/me/git/clones/linuxtv.org/new_build/v4l  modules
make[3]: Entering directory `/usr/src/linux-headers-2.6.32-25-3dbc39-generic'
  CC [M]  /home/me/git/clones/linuxtv.org/new_build/v4l/tuner-xc2028.o
  CC [M]  /home/me/git/clones/linuxtv.org/new_build/v4l/tuner-simple.o
  CC [M]  /home/me/git/clones/linuxtv.org/new_build/v4l/tuner-types.o
  CC [M]  /home/me/git/clones/linuxtv.org/new_build/v4l/mt20xx.o
...all ok so far...
  CC [M]  /home/me/git/clones/linuxtv.org/new_build/v4l/flexcop-dma.o
/home/me/git/clones/linuxtv.org/new_build/v4l/dvbdev.c:108: error:
'noop_llseek' undeclared here (not in a function)
make[4]: *** [/home/me/git/clones/linuxtv.org/new_build/v4l/dvbdev.o] Error 1
make[3]: *** [_module_/home/me/git/clones/linuxtv.org/new_build/v4l] Error 2
make[3]: Leaving directory `/usr/src/linux-headers-2.6.32-25-3dbc39-generic'
make[2]: *** [default] Error 2
make[2]: Leaving directory `/home/me/git/clones/linuxtv.org/new_build/v4l'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/home/me/git/clones/linuxtv.org/new_build'
make: *** [default] Error 2

Is it that an additional backport patch may be needed here?

The kernel I am running here is Ubuntu 2.6.32-25.43-generic (2.6.32.21+drm33.7)
with one tiny patch, reverting a bad change to drivers/usb/serial/ftdi_sio.c.

Any advice appreciated.

[1] http://git.linuxtv.org/media_tree.git

Re: new_build on ubuntu (dvbdev.c)

[Andy Walls]

On Sun, 2010-11-14 at 09:08 +1100, Vincent McIntyre wrote:
> Hi,
> I'm trying to build on 2.6.32 (ubuntu lucid i386).
> 
> I followed the instructions for building from git[1]

Shouldn't you be building from:

	http://git.linuxtv.org/mchehab/new_build.git

for backward compat builds? (I'm not sure myself.)

> but I get an error I don't understand.
> 
> make -C /lib/modules/2.6.32-25-3dbc39-generic/build
> SUBDIRS=/home/me/git/clones/linuxtv.org/new_build/v4l  modules
> make[3]: Entering directory `/usr/src/linux-headers-2.6.32-25-3dbc39-generic'
>   CC [M]  /home/me/git/clones/linuxtv.org/new_build/v4l/tuner-xc2028.o
>   CC [M]  /home/me/git/clones/linuxtv.org/new_build/v4l/tuner-simple.o
>   CC [M]  /home/me/git/clones/linuxtv.org/new_build/v4l/tuner-types.o
>   CC [M]  /home/me/git/clones/linuxtv.org/new_build/v4l/mt20xx.o
> ...all ok so far...
>   CC [M]  /home/me/git/clones/linuxtv.org/new_build/v4l/flexcop-dma.o
> /home/me/git/clones/linuxtv.org/new_build/v4l/dvbdev.c:108: error:
> 'noop_llseek' undeclared here (not in a function)

noop_llseek() is a newer kernl function that provided a trivial llseek()
implmenetation for drivers that don't support llseek() but still want to
provide a successful return code:

http://lkml.org/lkml/2010/4/9/193
http://lkml.org/lkml/2010/4/9/184


> Is it that an additional backport patch may be needed here?

Yup.  It looks like you need something.  You'll need a patch to
implement the trivial noop_llseek() function available in the links
above.

> The kernel I am running here is Ubuntu 2.6.32-25.43-generic (2.6.32.21+drm33.7)
> with one tiny patch, reverting a bad change to drivers/usb/serial/ftdi_sio.c.
> 
> Any advice appreciated.

Regards,
Andy

> [1] http://git.linuxtv.org/media_tree.git
> --

Re: new_build on ubuntu (dvbdev.c)

[Vincent McIntyre]

Apologies, I replied off-list.

On 11/14/10, Andy Walls <awalls@md.metrocast.net> wrote:
> On Sun, 2010-11-14 at 09:08 +1100, Vincent McIntyre wrote:
>> Hi,
>> I'm trying to build on 2.6.32 (ubuntu lucid i386).
>>
>> I followed the instructions for building from git[1]
>
> Shouldn't you be building from:
>
> 	http://git.linuxtv.org/mchehab/new_build.git
>
> for backward compat builds? (I'm not sure myself.)

Yes, I am using this as described in the README (make tar DIR=foo;
make untar; make).

> noop_llseek() is a newer kernl function that provided a trivial llseek()
> implmenetation for drivers that don't support llseek() but still want to
> provide a successful return code:
>
> http://lkml.org/lkml/2010/4/9/193
> http://lkml.org/lkml/2010/4/9/184
>
Thanks for explaining this.

>> Is it that an additional backport patch may be needed here?
>
> Yup.  It looks like you need something.  You'll need a patch to
> implement the trivial noop_llseek() function available in the links
> above.

This is helpful, indeed.

First dumb question - (I'll try to minimise these)

 * Inspection of the patches new_build/backports shows all the patches
are to things in the v4l/ tree
 * Yet the patch you pointed to is to fs/read_write.c and include/linux/fs.h

So my question: should this function be implemented as a patch to
files outside the v4l/ tree
or as additional .c and .h files within the v4l top level. I guess the
latter would then need to be #included in a bunch of v4l files. I'm
mainly unsure of the convention here.

I checked the mkrufky tree mentioned in README.patches but that didn't help.
I also checked the mercurial tree and could not find any backport of
noop_llseek,
but I may have missed something.

The consumers of the function appear to be:
$ find v4l -exec grep -li noop_llseek {} \;
v4l/dvb_frontend.c
v4l/lirc_imon.c
v4l/lirc_dev.c
v4l/lirc_it87.c
v4l/imon.c
v4l/dvb_ca_en50221.c
v4l/dvb_net.c
v4l/dvbdev.c
v4l/lirc_sasem.c
v4l/av7110_av.c
v4l/av7110.c
v4l/av7110_ir.c
v4l/dst_ca.c
v4l/firedtv-ci.c

Re: new_build on ubuntu (dvbdev.c)

[Andy Walls]

On Sun, 2010-11-14 at 20:26 +1100, Vincent McIntyre wrote:
> On 11/14/10, Andy Walls <awalls@md.metrocast.net> wrote:
> > On Sun, 2010-11-14 at 09:08 +1100, Vincent McIntyre wrote:


> > noop_llseek() is a newer kernl function that provided a trivial llseek()
> > implmenetation for drivers that don't support llseek() but still want to
> > provide a successful return code:
> >
> > http://lkml.org/lkml/2010/4/9/193
> > http://lkml.org/lkml/2010/4/9/184
> >
> Thanks for explaining this.


> First dumb question - (I'll try to minimise these)
> 
>  * Inspection of the patches new_build/backports shows all the patches
> are to things in the v4l/ tree
>  * Yet the patch you pointed to is to fs/read_write.c and include/linux/fs.h
> 
> So my question: should this function be implemented as a patch to
> files outside the v4l/ tree

I'm not sure, I haven't looked at the build system.  I'm guessing no.

The build system *should* be using the kernel include files from your
distribution.  Patching up fs.h in the git tree may not have any effect,
and patching up fs/read_write.c in the git tree certainly won't have any
effect.

You also don't want to muck with your installed kernel files.

> or as additional .c and .h files within the v4l top level. I guess the
> latter would then need to be #included in a bunch of v4l files. I'm
> mainly unsure of the convention here.

1. A simple, stupid patch would just a statically defined, non-inline
noop_llseek() function in each affected .c file.

In this particular case I'm not sure adding a special .h file, a new .c
file, a way to build the new .c file, and a bunch of #include's is worth
it.

or

2. I suppose you could have a patch add a .h file that defined a
non-inline static noop_llseek() function and just #include that where
needed.  

or

3.  You could just add

	#define noop_llseek	NULL

instead of a real function in either of 1 or 2 above.

> I checked the mkrufky tree mentioned in README.patches but that didn't help.
> I also checked the mercurial tree and could not find any backport of
> noop_llseek,
> but I may have missed something.
> 
> The consumers of the function appear to be:
> $ find v4l -exec grep -li noop_llseek {} \;
> v4l/dvb_frontend.c
> v4l/lirc_imon.c
> v4l/lirc_dev.c
> v4l/lirc_it87.c
> v4l/imon.c
> v4l/dvb_ca_en50221.c
> v4l/dvb_net.c
> v4l/dvbdev.c
> v4l/lirc_sasem.c
> v4l/av7110_av.c
> v4l/av7110.c
> v4l/av7110_ir.c
> v4l/dst_ca.c
> v4l/firedtv-ci.c

Regards,
Andy

Re: new_build on ubuntu (dvbdev.c)

[Mauro Carvalho Chehab]

Em 14-11-2010 10:12, Andy Walls escreveu:
> On Sun, 2010-11-14 at 20:26 +1100, Vincent McIntyre wrote:
>> On 11/14/10, Andy Walls <awalls@md.metrocast.net> wrote:
>>> On Sun, 2010-11-14 at 09:08 +1100, Vincent McIntyre wrote:
> 
> 
>>> noop_llseek() is a newer kernl function that provided a trivial llseek()
>>> implmenetation for drivers that don't support llseek() but still want to
>>> provide a successful return code:
>>>
>>> http://lkml.org/lkml/2010/4/9/193
>>> http://lkml.org/lkml/2010/4/9/184
>>>
>> Thanks for explaining this.

I've added several patches for the new-build today, in order to make it compile
against older kernels. I tested compilation here with both RHEL6 (2.6.32) and
Fedora 14 (2.6.35) and compilation is working fine. Didn't test the drivers.
I'm not sure if the remote controller will properly work with my quick backport.

>> First dumb question - (I'll try to minimise these)
>>
>>  * Inspection of the patches new_build/backports shows all the patches
>> are to things in the v4l/ tree
>>  * Yet the patch you pointed to is to fs/read_write.c and include/linux/fs.h
>>
>> So my question: should this function be implemented as a patch to
>> files outside the v4l/ tree
> 
> I'm not sure, I haven't looked at the build system.  I'm guessing no.
> 
> The build system *should* be using the kernel include files from your
> distribution.  Patching up fs.h in the git tree may not have any effect,
> and patching up fs/read_write.c in the git tree certainly won't have any
> effect.
> 
> You also don't want to muck with your installed kernel files.

The patches generally reverse-apply some upstream change. Andy's approach
could be done via compat.h. I opted to just backport the upstream patch.

Anyway, there were other problems on it, due to other API changes, and to
the move of the rc-core from .../IR to .../rc directory.

I opted to simplify the backports, avoiding to duplicate the same patch on several
different directories.

>> or as additional .c and .h files within the v4l top level. I guess the
>> latter would then need to be #included in a bunch of v4l files. I'm
>> mainly unsure of the convention here.
> 
> 1. A simple, stupid patch would just a statically defined, non-inline
> noop_llseek() function in each affected .c file.
> 
> In this particular case I'm not sure adding a special .h file, a new .c
> file, a way to build the new .c file, and a bunch of #include's is worth
> it.
> 
> or
> 
> 2. I suppose you could have a patch add a .h file that defined a
> non-inline static noop_llseek() function and just #include that where
> needed.  
> 
> or
> 
> 3.  You could just add
> 
> 	#define noop_llseek	NULL
> 
> instead of a real function in either of 1 or 2 above.
> 
>> I checked the mkrufky tree mentioned in README.patches but that didn't help.
>> I also checked the mercurial tree and could not find any backport of
>> noop_llseek,
>> but I may have missed something.
>>
>> The consumers of the function appear to be:
>> $ find v4l -exec grep -li noop_llseek {} \;
>> v4l/dvb_frontend.c
>> v4l/lirc_imon.c
>> v4l/lirc_dev.c
>> v4l/lirc_it87.c
>> v4l/imon.c
>> v4l/dvb_ca_en50221.c
>> v4l/dvb_net.c
>> v4l/dvbdev.c
>> v4l/lirc_sasem.c
>> v4l/av7110_av.c
>> v4l/av7110.c
>> v4l/av7110_ir.c
>> v4l/dst_ca.c
>> v4l/firedtv-ci.c
> 
> Regards,
> Andy
> 
> --
> 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

Re: new_build on ubuntu (dvbdev.c)

[Vincent McIntyre]

On 11/15/10, Mauro Carvalho Chehab <maurochehab@gmail.com> wrote:
...
> I've added several patches for the new-build today, in order to make it
> compile
> against older kernels. I tested compilation here with both RHEL6 (2.6.32)
> and
> Fedora 14 (2.6.35) and compilation is working fine. Didn't test the drivers.
> I'm not sure if the remote controller will properly work with my quick
> backport.

Thanks  for those changes. The build completes now, with only three warnings.
I do have to say CONFIG_DVB_FIREDTV=n, it appears still to be a
problem on ubuntu.

>>> First dumb question - (I'll try to minimise these)
>>>
...
> The patches generally reverse-apply some upstream change. Andy's approach
> could be done via compat.h. I opted to just backport the upstream patch.
>
> Anyway, there were other problems on it, due to other API changes, and to
> the move of the rc-core from .../IR to .../rc directory.
>
> I opted to simplify the backports, avoiding to duplicate the same patch on
> several different directories.
>

I see that now, after some quality time in the backports directory. It
does look simpler.

I think my original problem was that somehow the patch in the
2.6.32_series to remove references to noop_llseek() was not applying
cleanly. No idea why, I flushed the logs I kept.

Thanks all, I'll give the new build a test run as soon as I get a chance.

Cheers
Vince