Re: Debug code in HG repositories

2011-04-03 Thread Mauro Carvalho Chehab 
Em 10-01-2011 23:10, Oliver Endriss escreveu:
 On Monday 10 January 2011 13:04:54 Mauro Carvalho Chehab wrote:
 Em 07-01-2011 21:56, Oliver Endriss escreveu:
 ...
 There are large pieces of driver code which are currently unused, and
 nobody can tell whether they will ever be needed.

 On the other hand a developer spent days writing this stuff, and now it
 does not exist anymore - without any trace!

 The problem is not, that it is missing in the current snapshot, but
 that it has never been in the git repository, and there is no way to
 recover it.

 The Mercurial tree will stay there forever. We still have there the old CVS 
 trees used by DVB and V4L development.

 Afaics, the only way to preserve this kind of code is 'out-of-tree'.
 It is a shame... :-(

 I see your point. It is harder for people to re-use that code, as they are 
 not
 upstream.
 
 The main problem is that they do not even know that the code exists.
 
 Maybe I should add some comment to the driver, that someone should look
 into the HG repository, before he starts re-inventing the wheel.
 
 It is easy to recover the changes with:

 $ gentree.pl 2.6.37 --strip_dead_code linux/ /tmp/stripped
 $ gentree.pl 2.6.37  linux/ /tmp/not_stripped
 $ diff -upr /tmp/stripped/ /tmp/not_stripped/ /tmp/revert_removed_code.patch

 As a reference and further discussions, I'm enclosing the diff.
 
 The resulting diff is far from complete.
 In fact, the most interesting parts are missing.
 
 Apparently, the command
 gentree.pl 2.6.37  linux/ /tmp/not_stripped
 stripped all '#if 0' blocks, which are not followed by a comment.
 Just compare the original ngene_av.c with the resulting version in
 /tmp/non_stripped.

Oliver,

I fixed the script. Sorry for taking a long time. Too much stuff here.
The fix patch were already merged at -hg.

It will now produce the right results. A regex expression were waiting for
 something after #if 1/#if 0, with is generally ok, as lines end with \n.
However, due to the usage of chomp, the \n character were removed, and the 
regex failed on lines with just '#if 0'.

-

On most places, the code inside #if 0 are just legacy stuff, where people
were trying to implement a different code for something. However, at ngene,
the code inside #if 0 are there just because the ngene developers didn't find
time yet to work on them. So, it may make sense to add those code into 
mainstream,
if people will uncomment part of those code. So, feel free to send me a patch
adding the commented code, if you need.

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

Re: [patch] addition to v2.6.35_i2c_new_probed_device.patch (was: Re: Debug code in HG repositories)

2011-01-14 Thread Vincent McIntyre 
On 1/13/11, Mauro Carvalho Chehab mche...@redhat.com wrote:

 This seems to be a relatively simple patch, inline below.
 This is against the linux-media tree,  I could not figure out how
 to turn it into a clean patch of
 media_build/backports/v2.6.35_i2c_new_probed_device.patch
 I did look for guidance on how to do this in
 media_build/README.patches  but could not find anything that looked
 relevant.

 Well, there are two ways for doing it:


Thanks for your explanation. I was quite puzzled for some time why I
could not find the commit id in the git log, now I understand why.


 The code now compiles for me but I don't know if it will actually
 work, I don't have the hardware.

 Ok, I did the above procedure, adding your patch to the diff. Please test.


That bit works now (from git, the tarball downloaded by build.sh
hasn't caught up).
Thanks for applying.

However the build now fails on a separate issue, which I'll put in a new thread.

Cheers
Vince
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [patch] addition to v2.6.35_i2c_new_probed_device.patch (was: Re: Debug code in HG repositories)

2011-01-13 Thread Mauro Carvalho Chehab 
Em 13-01-2011 02:43, Vincent McIntyre escreveu:
 On 1/12/11, Mauro Carvalho Chehab mche...@redhat.com wrote:
 
 which on the face of it suggests
   btty-input.c
 
 already handled, my mistake.
 
   cx88-input.c
 the search string was in a comment
 
   hdpvr-i2c.c
 see below
 
 
 I have no time currently to touch on it, since I still have lots of patches
 to
 take a look and submit for the merge window. So, if you have some time,
 could you please prepare and submit a patch fixing it?
 
 This seems to be a relatively simple patch, inline below.
 This is against the linux-media tree,  I could not figure out how
 to turn it into a clean patch of
 media_build/backports/v2.6.35_i2c_new_probed_device.patch
 I did look for guidance on how to do this in
 media_build/README.patches  but could not find anything that looked
 relevant.

Well, there are two ways for doing it:

1) with two copies of linux/, one without your changes, and the other with
your changes;

2) you may create a temporary tree, just to do your patch. That's the way
I use. To avoid causing any confusion, I generally create the second
tree with mercurial.

Something like:

$ cd media_build/linux/
$ hg init
$ hg add *
$ hg commit

Then, I change the files, and I do:

$ hg diff  ../backports/my_new_patch.patch

In this specific case, before actually changing the files, I would do:

$ patch -p1 -i ../backports/v2.6.35_i2c_new_probed_device.patch -R
$ hg commit
$ patch -p1 -i ../backports/v2.6.35_i2c_new_probed_device.patch
edit the files
$ hg diff  ../backports/v2.6.35_i2c_new_probed_device.patch

 The code now compiles for me but I don't know if it will actually
 work, I don't have the hardware.

Ok, I did the above procedure, adding your patch to the diff. Please test.

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

[patch] addition to v2.6.35_i2c_new_probed_device.patch (was: Re: Debug code in HG repositories)

2011-01-12 Thread Vincent McIntyre 
On 1/12/11, Mauro Carvalho Chehab mche...@redhat.com wrote:

 which on the face of it suggests
   btty-input.c

already handled, my mistake.

   cx88-input.c
the search string was in a comment

   hdpvr-i2c.c
see below


 I have no time currently to touch on it, since I still have lots of patches
 to
 take a look and submit for the merge window. So, if you have some time,
 could you please prepare and submit a patch fixing it?

This seems to be a relatively simple patch, inline below.
This is against the linux-media tree,  I could not figure out how
to turn it into a clean patch of
media_build/backports/v2.6.35_i2c_new_probed_device.patch
I did look for guidance on how to do this in
media_build/README.patches  but could not find anything that looked
relevant.

The code now compiles for me but I don't know if it will actually
work, I don't have the hardware.

Cheers
Vince

Signed-off-by: Vince McIntyre vincent.mcint...@gmail.com
---
 drivers/media/video/hdpvr/hdpvr-i2c.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/media/video/hdpvr/hdpvr-i2c.c
b/drivers/media/video/hdpvr/hdpvr-i2c.c
index 24966aa..129639a 100644
--- a/drivers/media/video/hdpvr/hdpvr-i2c.c
+++ b/drivers/media/video/hdpvr/hdpvr-i2c.c
@@ -59,7 +59,7 @@ static int hdpvr_new_i2c_ir(struct hdpvr_device
*dev, struct i2c_adapter *adap,
break;
}

-   return i2c_new_probed_device(adap, info, addr_list, NULL) == NULL ?
+   return i2c_new_probed_device(adap, info, addr_list) == NULL ?
   -1 : 0;
 }

-- 
1.7.0.4
From 1b44e5c3b2886224042d9c20649311c231db3ccd Mon Sep 17 00:00:00 2001
From: Vince McIntyre vincent.mcint...@gmail.com
Date: Thu, 13 Jan 2011 15:30:13 +1100
Subject: [PATCH] To compile against 2.6.32, drop extra arg when calling i2c_new_probed_device()

Signed-off-by: Vince McIntyre vincent.mcint...@gmail.com
---
 drivers/media/video/hdpvr/hdpvr-i2c.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/media/video/hdpvr/hdpvr-i2c.c b/drivers/media/video/hdpvr/hdpvr-i2c.c
index 24966aa..129639a 100644
--- a/drivers/media/video/hdpvr/hdpvr-i2c.c
+++ b/drivers/media/video/hdpvr/hdpvr-i2c.c
@@ -59,7 +59,7 @@ static int hdpvr_new_i2c_ir(struct hdpvr_device *dev, struct i2c_adapter *adap,
 		break;
 	}
 
-	return i2c_new_probed_device(adap, info, addr_list, NULL) == NULL ?
+	return i2c_new_probed_device(adap, info, addr_list) == NULL ?
 	   -1 : 0;
 }
 
-- 
1.7.0.4

Re: Debug code in HG repositories

2011-01-11 Thread Vincent McIntyre 
On 1/10/11, Mauro Carvalho Chehab mche...@redhat.com wrote:

 Thanks for your script, but it seems specific to your environment. Could you
 please make it more generic and perhaps patch the existing build.sh script?

I was mainly intending to show how I happen to do this. It's way too complicated
compared to build.sh, which is a really nice solution.

 It would be nice to have some optional parameters there, to make life easier
 for end-users.

I can certainly try to supply some patches but I'm not sure what
parameters you have in mind.
build.sh is such a nice simple method; my script attempts to do
everything via git which is
overkill unless one is actively developing. Perhaps I could rework
into a distinct build_git.sh.

Cheers
Vince
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Debug code in HG repositories

2011-01-11 Thread Vincent McIntyre 
On 1/10/11, Mauro Carvalho Chehab mche...@redhat.com wrote:
 Em 07-01-2011 23:02, Vincent McIntyre escreveu:
 On 1/8/11, Hans Verkuil hverk...@xs4all.nl wrote:

 Have you tried Mauro's media_build tree? I had to use it today to test a
 driver from git on a 2.6.35 kernel. Works quite nicely. Perhaps we should
 promote this more. I could add backwards compatibility builds to my daily
 build script that uses this in order to check for which kernel versions
 this compiles if there is sufficient interest.


 As an end-user I would be interested in seeing this added, since it
 will allow faster detection of breakage in the older versions. For
 instance building against 2.6.32 fails like this:

   CC [M]  /home/vjm/git/clones/linuxtv.org/new_build/v4l/hdpvr-i2c.o
 /home/vjm/git/clones/linuxtv.org/new_build/v4l/hdpvr-i2c.c: In
 function 'hdpvr_new_i2c_ir':
 /home/vjm/git/clones/linuxtv.org/new_build/v4l/hdpvr-i2c.c:62: error:
 too many arguments to function 'i2c_new_probed_device'
 make[4]: *** [/home/vjm/git/clones/linuxtv.org/new_build/v4l/hdpvr-i2c.o]
 Error 1
 make[3]: *** [_module_/home/vjm/git/clones/linuxtv.org/new_build/v4l]
 Error 2
 make[3]: Leaving directory
 `/usr/src/linux-headers-2.6.32-26-ec297b-generic'
 make[2]: *** [default] Error 2
 make[2]: Leaving directory
 `/home/vjm/git/clones/linuxtv.org/new_build/v4l'
 make[1]: *** [all] Error 2
 make[1]: Leaving directory `/home/vjm/git/clones/linuxtv.org/new_build'
 make: *** [default] Error 2

 It's unclear that adding this would cause a lot of extra work; the
 patches that need to be applied are quite few - a tribute to the
 design work!

 That's weird. Here, it compiles fine against my 2.6.32 kernel, as there's a
 patch that removes the extra parameter. I'll double check and add a fix
 if I found something wrong.

I think a couple of modules may have been missed;
$ cd media_build
$ grep -rl i2c_new_probed_device v4l | grep -v .o
v4l/cx23885-i2c.c
v4l/bttv-input.c
v4l/cx88-input.c
v4l/ivtv-i2c.c
v4l/hdpvr-i2c.c
v4l/v4l2-common.c
v4l/cx18-i2c.c
v4l/em28xx-cards.c

$ grep +++ backports/v2.6.35_i2c_new_probed_device.patch
+++ b/drivers/media/video/bt8xx/bttv-input.cTue Oct 26 14:17:09 2010 -0200
+++ b/drivers/media/video/cx18/cx18-i2c.c   Tue Oct 26 14:17:09 2010 -0200
+++ b/drivers/media/video/cx23885/cx23885-i2c.c Tue Oct 26 14:17:09 2010 -0200
+++ b/drivers/media/video/em28xx/em28xx-cards.c Tue Oct 26 14:17:09 2010 -0200
+++ b/drivers/media/video/ivtv/ivtv-i2c.c   Tue Oct 26 14:17:09 2010 -0200
+++ b/drivers/media/video/v4l2-common.c Tue Oct 26 14:17:09 2010 -0200
+++ b/drivers/media/video/ivtv/ivtv-i2c.c   Tue Oct 26 23:18:52 2010 -0200

which on the face of it suggests
  btty-input.c
  cx88-input.c
  hdpvr-i2c.c
need looking at.

I get the same result whether building from a git clone of media-tree
or via media_build/build.sh.

I am building against ubuntu 2.6.32-26-generic aka 2.6.32.24+drm33.11, on i386.
I am using just their kernel-headers package for the build. Usually it works ok.

Cheers
Vince
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Debug code in HG repositories

2011-01-11 Thread Mauro Carvalho Chehab 
Em 11-01-2011 08:37, Vincent McIntyre escreveu:
 On 1/10/11, Mauro Carvalho Chehab mche...@redhat.com wrote:
 
 Thanks for your script, but it seems specific to your environment. Could you
 please make it more generic and perhaps patch the existing build.sh script?
 
 I was mainly intending to show how I happen to do this. It's way too 
 complicated
 compared to build.sh, which is a really nice solution.
 
 It would be nice to have some optional parameters there, to make life easier
 for end-users.
 
 I can certainly try to supply some patches but I'm not sure what
 parameters you have in mind.
 build.sh is such a nice simple method; my script attempts to do
 everything via git which is
 overkill unless one is actively developing. Perhaps I could rework
 into a distinct build_git.sh.

That could be interesting. For those using git trees, the better way is to use
make -C linux DIR=git dir

This needs to be done just once, as it will store some info at 
linux/.linked_dir.
It will basically store there the directory with the git tree, and the hashes of
the original, media_build original copy and media_build copy after patched. 
Every
time someone tries to compile, it re-checks the hashes and re-copy the file from
the git tree, if needed.

Cheers,
Mauro
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Debug code in HG repositories

2011-01-11 Thread Mauro Carvalho Chehab 
Em 11-01-2011 08:47, Vincent McIntyre escreveu:
 On 1/10/11, Mauro Carvalho Chehab mche...@redhat.com wrote:
 Em 07-01-2011 23:02, Vincent McIntyre escreveu:
 On 1/8/11, Hans Verkuil hverk...@xs4all.nl wrote:

 Have you tried Mauro's media_build tree? I had to use it today to test a
 driver from git on a 2.6.35 kernel. Works quite nicely. Perhaps we should
 promote this more. I could add backwards compatibility builds to my daily
 build script that uses this in order to check for which kernel versions
 this compiles if there is sufficient interest.


 As an end-user I would be interested in seeing this added, since it
 will allow faster detection of breakage in the older versions. For
 instance building against 2.6.32 fails like this:

   CC [M]  /home/vjm/git/clones/linuxtv.org/new_build/v4l/hdpvr-i2c.o
 /home/vjm/git/clones/linuxtv.org/new_build/v4l/hdpvr-i2c.c: In
 function 'hdpvr_new_i2c_ir':
 /home/vjm/git/clones/linuxtv.org/new_build/v4l/hdpvr-i2c.c:62: error:
 too many arguments to function 'i2c_new_probed_device'
 make[4]: *** [/home/vjm/git/clones/linuxtv.org/new_build/v4l/hdpvr-i2c.o]
 Error 1
 make[3]: *** [_module_/home/vjm/git/clones/linuxtv.org/new_build/v4l]
 Error 2
 make[3]: Leaving directory
 `/usr/src/linux-headers-2.6.32-26-ec297b-generic'
 make[2]: *** [default] Error 2
 make[2]: Leaving directory
 `/home/vjm/git/clones/linuxtv.org/new_build/v4l'
 make[1]: *** [all] Error 2
 make[1]: Leaving directory `/home/vjm/git/clones/linuxtv.org/new_build'
 make: *** [default] Error 2

 It's unclear that adding this would cause a lot of extra work; the
 patches that need to be applied are quite few - a tribute to the
 design work!

 That's weird. Here, it compiles fine against my 2.6.32 kernel, as there's a
 patch that removes the extra parameter. I'll double check and add a fix
 if I found something wrong.
 
 I think a couple of modules may have been missed;
 $ cd media_build
 $ grep -rl i2c_new_probed_device v4l | grep -v .o
 v4l/cx23885-i2c.c
 v4l/bttv-input.c
 v4l/cx88-input.c
 v4l/ivtv-i2c.c
 v4l/hdpvr-i2c.c
 v4l/v4l2-common.c
 v4l/cx18-i2c.c
 v4l/em28xx-cards.c
 
 $ grep +++ backports/v2.6.35_i2c_new_probed_device.patch
 +++ b/drivers/media/video/bt8xx/bttv-input.cTue Oct 26 14:17:09 2010 -0200
 +++ b/drivers/media/video/cx18/cx18-i2c.c   Tue Oct 26 14:17:09 2010 -0200
 +++ b/drivers/media/video/cx23885/cx23885-i2c.c Tue Oct 26 14:17:09 2010 -0200
 +++ b/drivers/media/video/em28xx/em28xx-cards.c Tue Oct 26 14:17:09 2010 -0200
 +++ b/drivers/media/video/ivtv/ivtv-i2c.c   Tue Oct 26 14:17:09 2010 -0200
 +++ b/drivers/media/video/v4l2-common.c Tue Oct 26 14:17:09 2010 -0200
 +++ b/drivers/media/video/ivtv/ivtv-i2c.c   Tue Oct 26 23:18:52 2010 -0200
 
 which on the face of it suggests
   btty-input.c
   cx88-input.c
   hdpvr-i2c.c
 need looking at.
 
 I get the same result whether building from a git clone of media-tree
 or via media_build/build.sh.
 
 I am building against ubuntu 2.6.32-26-generic aka 2.6.32.24+drm33.11, on 
 i386.
 I am using just their kernel-headers package for the build. Usually it works 
 ok.

I have no time currently to touch on it, since I still have lots of patches to
take a look and submit for the merge window. So, if you have some time,
could you please prepare and submit a patch fixing it?

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

Re: Debug code in HG repositories

2011-01-10 Thread Mauro Carvalho Chehab 
Em 07-01-2011 19:06, Hans Verkuil escreveu:
 On Friday, January 07, 2011 21:13:31 Devin Heitmueller wrote:
 On Fri, Jan 7, 2011 at 2:53 PM, Oliver Endriss o.endr...@gmx.de wrote:
 Hi guys,

 are you aware that there is a lot of '#if 0' code in the HG repositories
 which is not in GIT?

 When drivers were submitted to the kernel from HG, the '#if 0' stuff was
 stripped, unless it was marked as 'keep'...

 This was fine, when development was done with HG.

 As GIT is being used now, that code will be lost, as soon as the HG
 repositories have been removed...

 Any opinions how this should be handled?

Oliver,

There are some code there that it may make sense to bring back to -git and to
upstream, or to convert into some of the new kernel tracing facilities, but we
need to review them, as there are some codes inside the #if 0 that are simply 
dead code, where people were intending to use some alternative way to implement 
the driver, but gave up and just forgot to clean up the mess. Several of those
code don't even compile today, due to the kABI changes.

With respect to debug printk messages, I dunno if you've already used, but
dev_dbg() functions (and other similar ones) are very interesting: depending
on the way you compile your kernel, they're converted into dynamic_printk's, 
and they can be enabled/disabled via /sys/kernel/debug/. It is a way better than
just adding normal printk's, as you can tell the kernel to enable just the debug
message at some line.

For example:

$ cat /sys/kernel/debug/dynamic_debug/control |grep cx231xx
/home/v4l/new_build/v4l/cx231xx-input.c:93 [cx231xx]cx231xx_ir_init - Trying 
to bind ir at bus %d, addr 0x%02x\012
/home/v4l/new_build/v4l/cx231xx-input.c:57 [cx231xx]cx231xx_ir_init - %s\012
/home/v4l/new_build/v4l/cx231xx-input.c:45 [cx231xx]get_key_isdbt - scancode = 
%02x\012
/home/v4l/new_build/v4l/cx231xx-input.c:32 [cx231xx]get_key_isdbt - %s\012

by using:

# echo file cx231xx-input.c +p  /sys/kernel/debug/dynamic_debug/control

All the above debug lines will be enabled. You can do, instead:

# echo file cx231xx-input.c line 45 +p  
/sys/kernel/debug/dynamic_debug/control

If you're interested just at the scancode printk line.

At least on the distros I use (RHEL6 and Fedora 14), dynamic printk support is 
enabled
by default on kernel, so, this is very useful to me, as I don't need to 
recompile
the entire kernel to test.


 CU
 Oliver

 I complained about this months ago.  The problem is that when we were
 using HG, the HG repo was a complete superset of what went into Git
 (including development/debug code).  But now that we use Git, neither
 is a superset of the other.

 If you base your changes on Git, you have to add back in all the
 portability code (and any #if 0 you added as the maintainer for
 development/debugging).  Oh, and regular users cannot test any of your
 changes because they aren't willing to upgrade their entire kernel.

 If you base your changes on Hg, nothing merges cleanly when submitted
 upstream so your patches get rejected.

 Want to know why we are seeing regressions all over the place?
 Because *NOBODY* is testing the code until after the kernel goes
 stable (since while many are willing to install a v4l-dvb tree, very
 few will are willing to upgrade their entire kernel just to test one
 driver).  We've probably lost about 98% of our user base of testers.
 
 Have you tried Mauro's media_build tree? I had to use it today to test a
 driver from git on a 2.6.35 kernel. Works quite nicely. Perhaps we should
 promote this more. I could add backwards compatibility builds to my daily
 build script that uses this in order to check for which kernel versions
 this compiles if there is sufficient interest.

I'm using it currently on most of my tests. I know that there are several
users using it.

 Oh, and users have to git clone 500M+ of data, and not everybody in
 the world has bandwidth fast enough to make that worth their time (it
 took me several hours last time I did it).
 
 Currently the media_build tree copies the drivers from a git tree. Which, as
 you say, can be a big problem for non-developers. But all it really needs are
 the media drivers. So perhaps it might be a good idea to make a daily snapshot
 of the drivers and make it available for download on linuxtv.org. That archive
 is only 3.5 MB, so much easier to download.

No, you don't need to have it. Have you looked at the build.sh script?
It downloads and compiles everything using the latest tarball from:
http://linuxtv.org/downloads/drivers/
Currently, the archive has 3.3Mb. The tarball is updated when a change is
done on the latest development branch (It is still pointing to 
staging/for_v2.6.38,
as I didn't finish to add the backport to linux-next changes).

 Anyway, I've beaten this horse to death and it's fallen on deaf ears.
 Merge overhead has reached the point where it's just not worth my
 time/effort to submit anything upstream anymore.
 
 The hg tree is dead. Douglas

Re: Debug code in HG repositories

2011-01-10 Thread Mauro Carvalho Chehab 
Em 07-01-2011 21:42, Theodore Kilgore escreveu:
 
 Have you tried Mauro's media_build tree? I had to use it today to test a
 driver from git on a 2.6.35 kernel. Works quite nicely. Perhaps we 
 should
 promote this more. 
 
 Probably a good idea. I have been too busy to know about it, myself. And I 
 even do try to keep up with what is going on.
 
 I could add backwards compatibility builds to my 
 daily
 build script that uses this in order to check for which kernel versions
 this compiles if there is sufficient interest.
 
 Nice, but don't bust your behind with a thing like that. Back when we were 
 discussing the idea of getting off of hg and onto git, I suggested 
 approximately the previous three minor versions of the kernel, no 
 more. And if there was a serious problem with 2.(current_release - 1) or 
 2.(current_release - 2) such as instability or security issues, whatever, 
 then just drop that one. I think that to do this is reasonable if you or 
 anyone else has the time and needed skills. More than this is not 
 reasonable under any circumstances.

I think Hans can enable it. The backport effort on media-build is a way
easier than with -hg. For example, in order to support kernel 2.6.31 (the oldest
one on that tree), we need only 10 patches. The patches themself are simple:

$ wc -l *.patch
   61 v2.6.31_nodename.patch
  540 v2.6.32_kfifo.patch
   42 v2.6.33_input_handlers_are_int.patch
   70 v2.6.33_pvrusb2_sysfs.patch
   40 v2.6.34_dvb_net.patch
   22 v2.6.34_fix_define_warnings.patch
   16 v2.6.35_firedtv_handle_fcp.patch
  104 v2.6.35_i2c_new_probed_device.patch
  145 v2.6.35_work_handler.patch
  104 v2.6.36_input_getkeycode.patch
 1144 total

And almost all patches are trivial.

 Now, as to the question of switching over to and using git, here are my 
 recent personal experiences:
 
 I started to do this switch-over only about a month ago, having been too 
 busy for several months previous due to an illness in the family. I found 
 that everything had changed in the meantime, and the hg trees had gone 
 away. 
 
 Issue 0: This issue came up just as I was deciding to switch from 32 to 64 
 bit computing, so a lot of other stuff needed to be fixed or upgraded at 
 the same time. I was busy. Well, lots of people are busy, and for lots of 
 reasons. 
 
 Issue 1: Which git tree? For someone who is going to get in at the 
 beginning, this is not obvious. This issue got solved, of course, but it 
 was the first one to face. For an outsider, I suspect that even this is 
 somewhat intimidating.

It is now well-indicated at the top of the git page at linuxtv.org.

 Issue 2: Problems totally unrelated to drivers/media rendered the new 
 kernel unusable for very a long time, approximately a couple of weeks. I 
 think I can call myself experienced in kernel configuration and 
 compilation, and also not a total neophyte as a developer. The issue was a 
 rather evil interaction between the new kernel, the new X driver for the 
 ATI Radeon chip, and the introduction of in-kernel modeswitching (KMS) in 
 X. It came about that if KMS was turned on then the video would cut off 
 completely halfway through the boot procedure, and if KMS was turned off 
 then I could not run X. I could use the distro kernel 2.6.35.7 and a 
 locally compiled 2.6.35.7 as well just fine, but I could not safely submit 
 a patch based on it. And my patches could not be tested against the git 
 kernel because I could not run the git kernel. This problem was ultimately 
 solved, and I was able to submit a rather small patch to add a camera to 
 an existing driver, on Christmas Eve. 

Yeah, KMS also affected me for some time on -git builds, until it become more
stable. The solution I used were to not start X on my test machine during that
period of time.

Anyway, with media_build tree, you can compile it against your 2.6.35.7 kernel.
Depending on what you're doing, this should be ok. 

Yet, with BKL changes, the better for developers is to use kernel 2.6.37 or 
upper, 
in orderto be sure that the driver will work properly without BKL and without 
any 
race/dead lock issue.

 Issue 3: I still need to grab the git tree for libv4l and start using it. 
 I have not even begun this. For some of the reasons why I am behind 
 schedule, see previous items.

You should really use it, as some webcam fixes happen there (like some 
sensors mounted with vflip/hflip). Fedora ships it by default, and most
applications there calls it. Not sure why some distros are still not
shipping it properly.

 The point is, problems similar to those which hit me could hit anybody at 
 any time and anybody means exactly what it says. This was not the first 
 time that I have installed a development kernel. It was the first time I 
 had any serious problems after doing so. Now, it is also true that after I 
 finally got the issues worked through I was pleased with the results and 
 would still run the new kernel by preference. But the problems were 
 extremely time

Re: Debug code in HG repositories

2011-01-10 Thread Mauro Carvalho Chehab 
Em 07-01-2011 21:56, Oliver Endriss escreveu:
 On Friday 07 January 2011 22:06:30 Hans Verkuil wrote:
 On Friday, January 07, 2011 21:13:31 Devin Heitmueller wrote:
 On Fri, Jan 7, 2011 at 2:53 PM, Oliver Endriss o.endr...@gmx.de wrote:
 Hi guys,

 are you aware that there is a lot of '#if 0' code in the HG repositories
 which is not in GIT?

 When drivers were submitted to the kernel from HG, the '#if 0' stuff was
 stripped, unless it was marked as 'keep'...

 This was fine, when development was done with HG.

 As GIT is being used now, that code will be lost, as soon as the HG
 repositories have been removed...

 Any opinions how this should be handled?

 CU
 Oliver

 I complained about this months ago.  The problem is that when we were
 using HG, the HG repo was a complete superset of what went into Git
 (including development/debug code).  But now that we use Git, neither
 is a superset of the other.

 If you base your changes on Git, you have to add back in all the
 portability code (and any #if 0 you added as the maintainer for
 development/debugging).  Oh, and regular users cannot test any of your
 changes because they aren't willing to upgrade their entire kernel.

 If you base your changes on Hg, nothing merges cleanly when submitted
 upstream so your patches get rejected.

 Want to know why we are seeing regressions all over the place?
 Because *NOBODY* is testing the code until after the kernel goes
 stable (since while many are willing to install a v4l-dvb tree, very
 few will are willing to upgrade their entire kernel just to test one
 driver).  We've probably lost about 98% of our user base of testers.

 Have you tried Mauro's media_build tree? I had to use it today to test a
 driver from git on a 2.6.35 kernel. Works quite nicely. Perhaps we should
 promote this more. I could add backwards compatibility builds to my daily
 build script that uses this in order to check for which kernel versions
 this compiles if there is sufficient interest.

 Oh, and users have to git clone 500M+ of data, and not everybody in
 the world has bandwidth fast enough to make that worth their time (it
 took me several hours last time I did it).

 Currently the media_build tree copies the drivers from a git tree. Which, as
 you say, can be a big problem for non-developers. But all it really needs are
 the media drivers. So perhaps it might be a good idea to make a daily 
 snapshot
 of the drivers and make it available for download on linuxtv.org. That 
 archive
 is only 3.5 MB, so much easier to download.

 Anyway, I've beaten this horse to death and it's fallen on deaf ears.
 Merge overhead has reached the point where it's just not worth my
 time/effort to submit anything upstream anymore.

 The hg tree is dead. Douglas Landgraf tried to maintain it, but it's just too
 much work. Any attempt to work from the hg tree is doomed. The media_build
 seems to be a viable alternative. As a developer you still have to go through
 the painful process of cloning the git repo, but it is a one time thing. Once
 it's cloned then you only have to follow the new commits, which is much, much
 faster.

 And regarding regressions: I'm amazed how few regressions we have considering
 the furious rate of development. The media subsystem is still one of the most
 active subsystems in the kernel and probably will remain so for the 
 forseeable
 future as well.
 
 Regressions can be detected only if you have enough testers!
 
 With the current situation, it is very likely that regressions will not
 show up before major linux distributions switch to a new kernel.
 Afaics the user base is neglectible at the moment. So you can expect
 that regressions will show up months after release of a new kernel.

Fedora code is released on every 6 months, generally with the newest code from
V4L/DVB. Fedora rawhide always have the latest kernel. I'm sure that other 
distros
have similar development procedures. So, even if nobody is using 
media_build.git, 
there are many users with access to the latest code, that come to them via 
distros.

There are very few regressions reported.

Of course, it would be great if more people start using media_build.git, as 
we'll
have more testers.
 
 Anyway, this is off-topic. I was not talking about regressions.
 
 It would be a shame not to submit patches upstream, that never ends well in
 the long run.

 With respect to '#if 0': for the most part I'd say: good riddance. In my
 many years of experience as a SW engineer I have never seen anyone actually
 turn on '#if 0' code once it's been in the code for more than, say, a year.
 Usually people just leave it there because they are too lazy to remove it,
 or they don't understand what it is for and are too scared to remove it.

 If it is code partially implementing a feature that needs more work, then
 it may sound like a good idea to keep it. However, after it's in the code for
 more than a year, then nobody remembers what the code was about and what 
 still
 had to

Re: Debug code in HG repositories

2011-01-10 Thread Mauro Carvalho Chehab 
Em 10-01-2011 10:04, Mauro Carvalho Chehab escreveu:
 Em 07-01-2011 21:56, Oliver Endriss escreveu:
 On Friday 07 January 2011 22:06:30 Hans Verkuil wrote:
 On Friday, January 07, 2011 21:13:31 Devin Heitmueller wrote:
 On Fri, Jan 7, 2011 at 2:53 PM, Oliver Endriss o.endr...@gmx.de wrote:
 Hi guys,

 are you aware that there is a lot of '#if 0' code in the HG repositories
 which is not in GIT?

 As a reference and further discussions, I'm enclosing the diff.

It is now easier to comment on what we have inside the #if 0 code. Let me add
my comments about that.

A general comment after my review is that most of the commented code should
be just discarded, but I agree with Oliver that there are some things there
that we want to preserve.

 
 ---
 
 diff -upr /tmp/stripped/drivers/media/common/tuners/tea5767.c 
 /tmp/not_stripped/drivers/media/common/tuners/tea5767.c
 --- /tmp/stripped/drivers/media/common/tuners/tea5767.c   2011-01-10 
 10:01:50.0 -0200
 +++ /tmp/not_stripped/drivers/media/common/tuners/tea5767.c   2011-01-10 
 10:02:06.0 -0200
 @@ -371,6 +371,9 @@ int tea5767_autodetection(struct i2c_ada
   struct tuner_i2c_props i2c = { .adap = i2c_adap, .addr = i2c_addr };
   unsigned char buffer[7] = { 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff };
   int rc;
 +#if 0 /* Needed if uncomment I2C send code below */
 + int div;
 +#endif
  
   if ((rc = tuner_i2c_xfer_recv(i2c, buffer, 7)) 5) {
   printk(KERN_WARNING It is not a TEA5767. Received %i 
 bytes.\n, rc);
 @@ -394,7 +397,42 @@ int tea5767_autodetection(struct i2c_ada
   return -EINVAL;
   }
  
 +#if 0/* Not working for TEA5767 in Beholder Columbus card */
 + /* It seems that tea5767 returns 0xff after the 5th byte */
 + if ((buffer[5] != 0xff) || (buffer[6] != 0xff)) {
 + printk(KERN_WARNING Returned more than 5 bytes. It is not a 
 TEA5767\n);
 + return -EINVAL;
 + }
 +#endif
 +
 +#if 0 /*Sometimes, this code doesn't work */
 + /* Sets tuner at some freq (87.5 MHz) and see if it is ok */
 + div = ((87500 * 4000 + 70 + 225000) + 16768)  15;
 + buffer[0] = ((div  8)  0x3f) | TEA5767_MUTE;
 + buffer[1] = div  0xff;
 + buffer[2] = TEA5767_PORT1_HIGH;
 + buffer[3] = TEA5767_PORT2_HIGH | TEA5767_HIGH_CUT_CTRL |
 + TEA5767_ST_NOISE_CTL;
 + buffer[4] = 0;
 +
 + if (5 != (rc = tuner_i2c_xfer_send(i2c, buffer, 5)))
 + printk(KERN_WARNING i2c i/o error: rc == %d (should be 5)\n, 
 rc);
 +
 + msleep(15);
 +
 + if (5 != (rc = tuner_i2c_xfer_recv(i2c, buffer, 5))) {
 + printk(KERN_WARNING It is not a TEA5767. Received %i 
 bytes.\n, rc);
 + return -EINVAL;
 + }
  
 + /* Initial freq for 32.768KHz clock */
 + if ((buffer[1] != (div  0xff) ) || ((buffer[0]  0x3f) != ((div  8) 
  0x3f))) {
 + printk(KERN_WARNING It is not a TEA5767. div=%d, Return: %02x 
 %02x %02x %02x %02x\n,
 + 
 div,buffer[0],buffer[1],buffer[2],buffer[3],buffer[4]);
 + tea5767_status_dump(buffer);
 + return -EINVAL;
 + }
 +#endif
   return 0;
  }
  
 @@ -443,6 +481,10 @@ struct dvb_frontend *tea5767_attach(stru
  {
   struct tea5767_priv *priv = NULL;
  
 +#if 0 /* By removing autodetection allows forcing TEA chip */
 + if (tea5767_autodetection(i2c_adap, i2c_addr) == -EINVAL)
 + return -EINVAL;
 +#endif
   priv = kzalloc(sizeof(struct tea5767_priv), GFP_KERNEL);
   if (priv == NULL)
   return NULL;

All the #if 0 code there are obsolete. The detection tests
were moved to other place.

 diff -upr /tmp/stripped/drivers/media/common/tuners/tuner-simple.c 
 /tmp/not_stripped/drivers/media/common/tuners/tuner-simple.c
 --- /tmp/stripped/drivers/media/common/tuners/tuner-simple.c  2011-01-10 
 10:01:50.0 -0200
 +++ /tmp/not_stripped/drivers/media/common/tuners/tuner-simple.c  
 2011-01-10 10:02:06.0 -0200
 @@ -161,6 +161,12 @@ static inline int tuner_afcstatus(const 
   return (status  TUNER_AFC) - 2;
  }
  
 +#if 0 /* unused */
 +static inline int tuner_mode(const int status)
 +{
 + return (status  TUNER_MODE)  3;
 +}
 +#endif
  
  static int simple_get_status(struct dvb_frontend *fe, u32 *status)
  {

No idea about that. Too old for me to remember, but I don't think
we should backport it.

 diff -upr /tmp/stripped/drivers/media/dvb/ngene/ngene-cards.c 
 /tmp/not_stripped/drivers/media/dvb/ngene/ngene-cards.c
 --- /tmp/stripped/drivers/media/dvb/ngene/ngene-cards.c   2011-01-10 
 10:01:49.0 -0200
 +++ /tmp/not_stripped/drivers/media/dvb/ngene/ngene-cards.c   2011-01-10 
 10:02:05.0 -0200
 @@ -272,6 +272,32 @@ static const struct pci_device_id ngene_
   NGENE_ID(0x18c3, 0xdd10, ngene_info_duoFlexS2),
   NGENE_ID(0x18c3, 0xdd20, ngene_info_duoFlexS2),
   NGENE_ID(0x1461, 0x062e, ngene_info_m780),
 +#if 0 /* not

Re: Debug code in HG repositories

2011-01-10 Thread Mauro Carvalho Chehab 
Em 07-01-2011 23:02, Vincent McIntyre escreveu:
 On 1/8/11, Hans Verkuil hverk...@xs4all.nl wrote:
 
 Have you tried Mauro's media_build tree? I had to use it today to test a
 driver from git on a 2.6.35 kernel. Works quite nicely. Perhaps we should
 promote this more. I could add backwards compatibility builds to my daily
 build script that uses this in order to check for which kernel versions
 this compiles if there is sufficient interest.

 
 As an end-user I would be interested in seeing this added, since it
 will allow faster detection of breakage in the older versions. For
 instance building against 2.6.32 fails like this:
 
   CC [M]  /home/vjm/git/clones/linuxtv.org/new_build/v4l/hdpvr-i2c.o
 /home/vjm/git/clones/linuxtv.org/new_build/v4l/hdpvr-i2c.c: In
 function 'hdpvr_new_i2c_ir':
 /home/vjm/git/clones/linuxtv.org/new_build/v4l/hdpvr-i2c.c:62: error:
 too many arguments to function 'i2c_new_probed_device'
 make[4]: *** [/home/vjm/git/clones/linuxtv.org/new_build/v4l/hdpvr-i2c.o]
 Error 1
 make[3]: *** [_module_/home/vjm/git/clones/linuxtv.org/new_build/v4l] Error 2
 make[3]: Leaving directory `/usr/src/linux-headers-2.6.32-26-ec297b-generic'
 make[2]: *** [default] Error 2
 make[2]: Leaving directory `/home/vjm/git/clones/linuxtv.org/new_build/v4l'
 make[1]: *** [all] Error 2
 make[1]: Leaving directory `/home/vjm/git/clones/linuxtv.org/new_build'
 make: *** [default] Error 2
 
 It's unclear that adding this would cause a lot of extra work; the
 patches that need to be applied are quite few - a tribute to the
 design work!

That's weird. Here, it compiles fine against my 2.6.32 kernel, as there's a
patch that removes the extra parameter. I'll double check and add a fix
if I found something wrong.

 For what it's worth, I've attached the shell script I use to pull
 updates and do a new build.
 Doing the initial setup is well explained by the
 linuxtv.org/media_tree.git page,
 but this script may be of use to end users wanting to track development.

Thanks for your script, but it seems specific to your environment. Could you
please make it more generic and perhaps patch the existing build.sh script?
It would be nice to have some optional parameters there, to make life easier
for end-users.

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

Re: Debug code in HG repositories

2011-01-10 Thread Johannes Stezenbach 
On Mon, Jan 10, 2011 at 09:46:40AM -0200, Mauro Carvalho Chehab wrote:
 Em 07-01-2011 21:42, Theodore Kilgore escreveu:
  
  Have you tried Mauro's media_build tree? I had to use it today to test a
  driver from git on a 2.6.35 kernel. Works quite nicely. Perhaps we 
  should
  promote this more. 
  
  Probably a good idea. I have been too busy to know about it, myself. And I 
  even do try to keep up with what is going on.
  
  I could add backwards compatibility builds to my 
  daily
  build script that uses this in order to check for which kernel versions
  this compiles if there is sufficient interest.
...
 I think Hans can enable it. The backport effort on media-build is a way
 easier than with -hg. For example, in order to support kernel 2.6.31 (the 
 oldest
 one on that tree), we need only 10 patches. The patches themself are simple:
 
 $ wc -l *.patch
61 v2.6.31_nodename.patch
   540 v2.6.32_kfifo.patch
42 v2.6.33_input_handlers_are_int.patch
70 v2.6.33_pvrusb2_sysfs.patch
40 v2.6.34_dvb_net.patch
22 v2.6.34_fix_define_warnings.patch
16 v2.6.35_firedtv_handle_fcp.patch
   104 v2.6.35_i2c_new_probed_device.patch
   145 v2.6.35_work_handler.patch
   104 v2.6.36_input_getkeycode.patch
  1144 total
 
 And almost all patches are trivial.

FWIW, linux-wireless developers maintain a generic compat tree used
for backporting wireless drivers:
http://git.kernel.org/?p=linux/kernel/git/mcgrof/compat.git;a=summary

I suppose it might be useful to share this between linux-wireless
and linux-media?


(It is used together with three other trees to autobuild
the compat-wireless releases.
http://wireless.kernel.org/en/users/Download

It works like that:
- compat.git: generic backporting layer
- compat-wireless-2.6.git: build system
- compat-user.git: autobuild scripts called via cron
- wireless-testing.git: linux-wireless development tree

(wireless-testing.git is based on latest stable kernel but with
the wireless code from linux-next)

compat-wireless releases are not meant for development, but
they can be used as a build system together with a wireless-testing.git
tree and a few symlinks.)


Johannes
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Debug code in HG repositories

2011-01-10 Thread Theodore Kilgore 

Mauro,

A few comments in-line. Vide infra.

On Mon, 10 Jan 2011, Mauro Carvalho Chehab wrote:

 Em 07-01-2011 21:42, Theodore Kilgore escreveu:
  
  Have you tried Mauro's media_build tree? I had to use it today to test a
  driver from git on a 2.6.35 kernel. Works quite nicely. Perhaps we 
  should
  promote this more. 
  
  Probably a good idea. I have been too busy to know about it, myself. And I 
  even do try to keep up with what is going on.
  
  I could add backwards compatibility builds to my 
  daily
  build script that uses this in order to check for which kernel versions
  this compiles if there is sufficient interest.
  
  Nice, but don't bust your behind with a thing like that. Back when we were 
  discussing the idea of getting off of hg and onto git, I suggested 
  approximately the previous three minor versions of the kernel, no 
  more. And if there was a serious problem with 2.(current_release - 1) or 
  2.(current_release - 2) such as instability or security issues, whatever, 
  then just drop that one. I think that to do this is reasonable if you or 
  anyone else has the time and needed skills. More than this is not 
  reasonable under any circumstances.
 
 I think Hans can enable it. The backport effort on media-build is a way
 easier than with -hg. For example, in order to support kernel 2.6.31 (the 
 oldest
 one on that tree), we need only 10 patches. The patches themself are simple:
 
 $ wc -l *.patch
61 v2.6.31_nodename.patch
   540 v2.6.32_kfifo.patch
42 v2.6.33_input_handlers_are_int.patch
70 v2.6.33_pvrusb2_sysfs.patch
40 v2.6.34_dvb_net.patch
22 v2.6.34_fix_define_warnings.patch
16 v2.6.35_firedtv_handle_fcp.patch
   104 v2.6.35_i2c_new_probed_device.patch
   145 v2.6.35_work_handler.patch
   104 v2.6.36_input_getkeycode.patch
  1144 total
 
 And almost all patches are trivial.

Great. I am glad Hans is able to do that. I also think that before some 
changes were made things had reached the point of being both ridiculous 
and impossible. People doing the work were being run ragged, and demands 
for legacy support were obviously unreasonable. 

I forget what all of the issues were in the pre-2.6.20 kernels. I vaguely 
recall there were some really bad ones. One of them that I have personal 
knowledge about was a major error in the USB Mass Storage module, detected 
and fixed somewhere around 2.6.18. Namely, if a device says it is Class 08 
the spec says the first pair of bulk endpoints will be used. Before the 
fix, last pair was being searched instead. The mistake is not confronted 
very often, of course, because few USB devices have more than one pair of 
bulk endpoints. But for those that do, ouch. In fact, the hardware which 
brought the mistake to daylight was the same camera which is supported in 
gspca/jeilinj.c. In still mode as a standard mass storage device, that 
camera uses the first pair of bulk endpoints. As it is supposed to do. But 
until things were fixed, the mass storage support was attempting to use 
the second pair, which did not work out very well. The second pair of the 
bulk endpoints gets used only in webcam mode for passing commands and 
responses.

The point of the above story is that sometimes in kernel development 
things are changed from wrong to right. Those who petulantly want their 
favorite ancient kernel to be supported simply ought to understand and 
accept out of hand. Should any kernel prior to the fixing of the above 
problem continue in use in any environment where it needs to support USB 
mass storage devices? Obviously not. The moral for the present and future 
is obvious, too. 

 
  Now, as to the question of switching over to and using git, here are my 
  recent personal experiences:
  
  I started to do this switch-over only about a month ago, having been too 
  busy for several months previous due to an illness in the family. I found 
  that everything had changed in the meantime, and the hg trees had gone 
  away. 
  
  Issue 0: This issue came up just as I was deciding to switch from 32 to 64 
  bit computing, so a lot of other stuff needed to be fixed or upgraded at 
  the same time. I was busy. Well, lots of people are busy, and for lots of 
  reasons. 
  
  Issue 1: Which git tree? For someone who is going to get in at the 
  beginning, this is not obvious. This issue got solved, of course, but it 
  was the first one to face. For an outsider, I suspect that even this is 
  somewhat intimidating.
 
 It is now well-indicated at the top of the git page at linuxtv.org.

Nice.

 
  Issue 2: Problems totally unrelated to drivers/media rendered the new 
  kernel unusable for very a long time, approximately a couple of weeks. I 
  think I can call myself experienced in kernel configuration and 
  compilation, and also not a total neophyte as a developer. The issue was a 
  rather evil interaction between the new kernel, the new X driver for the 
  ATI Radeon chip, and the introduction of in-kernel

Re: Debug code in HG repositories

2011-01-10 Thread Oliver Endriss 
On Monday 10 January 2011 13:27:09 Mauro Carvalho Chehab wrote:
  ...
  diff -upr /tmp/stripped/drivers/media/dvb/ngene/ngene-cards.c 
  /tmp/not_stripped/drivers/media/dvb/ngene/ngene-cards.c
  --- /tmp/stripped/drivers/media/dvb/ngene/ngene-cards.c 2011-01-10 
  10:01:49.0 -0200
  +++ /tmp/not_stripped/drivers/media/dvb/ngene/ngene-cards.c 2011-01-10 
  10:02:05.0 -0200
  @@ -272,6 +272,32 @@ static const struct pci_device_id ngene_
  NGENE_ID(0x18c3, 0xdd10, ngene_info_duoFlexS2),
  NGENE_ID(0x18c3, 0xdd20, ngene_info_duoFlexS2),
  NGENE_ID(0x1461, 0x062e, ngene_info_m780),
  +#if 0 /* not (yet?) supported */
  +   NGENE_ID(0x18c3, 0x, ngene_info_appboard),
  +   NGENE_ID(0x18c3, 0x0004, ngene_info_appboard),
  +   NGENE_ID(0x18c3, 0x8011, ngene_info_appboard),
  +   NGENE_ID(0x18c3, 0x8015, ngene_info_appboard_ntsc),
  +   NGENE_ID(0x153b, 0x1167, ngene_info_terratec),
  +   NGENE_ID(0x18c3, 0x0030, ngene_info_python),
  +   NGENE_ID(0x18c3, 0x0052, ngene_info_sidewinder),
  +   NGENE_ID(0x18c3, 0x8f00, ngene_info_racer),
  +   NGENE_ID(0x18c3, 0x0041, ngene_info_viper_v1),
  +   NGENE_ID(0x18c3, 0x0042, ngene_info_viper_v2),
  +   NGENE_ID(0x14f3, 0x0041, ngene_info_vbox_v1),
  +   NGENE_ID(0x14f3, 0x0043, ngene_info_vbox_v2),
  +   NGENE_ID(0x18c3, 0xabcd, ngene_info_s2),
  +   NGENE_ID(0x18c3, 0xabc2, ngene_info_s2_b),
  +   NGENE_ID(0x18c3, 0xabc3, ngene_info_s2_b),
  +   NGENE_ID(0x18c3, 0x0001, ngene_info_appboard),
  +   NGENE_ID(0x18c3, 0x0005, ngene_info_appboard),
  +   NGENE_ID(0x18c3, 0x0009, ngene_info_appboard_atsc),
  +   NGENE_ID(0x18c3, 0x000b, ngene_info_appboard_atsc),
  +   NGENE_ID(0x18c3, 0x0010, ngene_info_shrek_50_fp),
  +   NGENE_ID(0x18c3, 0x0011, ngene_info_shrek_60_fp),
  +   NGENE_ID(0x18c3, 0x0012, ngene_info_shrek_50),
  +   NGENE_ID(0x18c3, 0x0013, ngene_info_shrek_60),
  +   NGENE_ID(0x18c3, 0x, ngene_info_hognose),
  +#endif
  {0}
   };
   MODULE_DEVICE_TABLE(pci, ngene_id_tbl);
 
 It is probably a good idea to backport this one. I would change it to #if 1, 
 to allow
 people to test (or I would create a CONFIG_NGENE_EXPERIMENTAL to enable such 
 support).

Nack, it would not work. If you have a look at a really unstripped ;-)
version of the file, you will notice that you have to invest a
considerable amount of effort to get these card types running.

This kind of stuff should be added one by one, whenever someone is
working on it.

CU
Oliver

-- 

VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/
4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/
Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Debug code in HG repositories

2011-01-07 Thread Devin Heitmueller 
On Fri, Jan 7, 2011 at 2:53 PM, Oliver Endriss o.endr...@gmx.de wrote:
 Hi guys,

 are you aware that there is a lot of '#if 0' code in the HG repositories
 which is not in GIT?

 When drivers were submitted to the kernel from HG, the '#if 0' stuff was
 stripped, unless it was marked as 'keep'...

 This was fine, when development was done with HG.

 As GIT is being used now, that code will be lost, as soon as the HG
 repositories have been removed...

 Any opinions how this should be handled?

 CU
 Oliver

I complained about this months ago.  The problem is that when we were
using HG, the HG repo was a complete superset of what went into Git
(including development/debug code).  But now that we use Git, neither
is a superset of the other.

If you base your changes on Git, you have to add back in all the
portability code (and any #if 0 you added as the maintainer for
development/debugging).  Oh, and regular users cannot test any of your
changes because they aren't willing to upgrade their entire kernel.

If you base your changes on Hg, nothing merges cleanly when submitted
upstream so your patches get rejected.

Want to know why we are seeing regressions all over the place?
Because *NOBODY* is testing the code until after the kernel goes
stable (since while many are willing to install a v4l-dvb tree, very
few will are willing to upgrade their entire kernel just to test one
driver).  We've probably lost about 98% of our user base of testers.

Oh, and users have to git clone 500M+ of data, and not everybody in
the world has bandwidth fast enough to make that worth their time (it
took me several hours last time I did it).

Anyway, I've beaten this horse to death and it's fallen on deaf ears.
Merge overhead has reached the point where it's just not worth my
time/effort to submit anything upstream anymore.

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Debug code in HG repositories

2011-01-07 Thread Theodore Kilgore 


On Fri, 7 Jan 2011, Hans Verkuil wrote:

 On Friday, January 07, 2011 21:13:31 Devin Heitmueller wrote:
  On Fri, Jan 7, 2011 at 2:53 PM, Oliver Endriss o.endr...@gmx.de wrote:
   Hi guys,
  
   are you aware that there is a lot of '#if 0' code in the HG repositories
   which is not in GIT?
  
   When drivers were submitted to the kernel from HG, the '#if 0' stuff was
   stripped, unless it was marked as 'keep'...
  
   This was fine, when development was done with HG.
  
   As GIT is being used now, that code will be lost, as soon as the HG
   repositories have been removed...
  
   Any opinions how this should be handled?
  
   CU
   Oliver
  
  I complained about this months ago.  The problem is that when we were
  using HG, the HG repo was a complete superset of what went into Git
  (including development/debug code).  But now that we use Git, neither
  is a superset of the other.
  
  If you base your changes on Git, you have to add back in all the
  portability code (and any #if 0 you added as the maintainer for
  development/debugging).  Oh, and regular users cannot test any of your
  changes because they aren't willing to upgrade their entire kernel.
  
  If you base your changes on Hg, nothing merges cleanly when submitted
  upstream so your patches get rejected.
  
  Want to know why we are seeing regressions all over the place?
  Because *NOBODY* is testing the code until after the kernel goes
  stable (since while many are willing to install a v4l-dvb tree, very
  few will are willing to upgrade their entire kernel just to test one
  driver).  We've probably lost about 98% of our user base of testers.
 
 Have you tried Mauro's media_build tree? I had to use it today to test a
 driver from git on a 2.6.35 kernel. Works quite nicely. Perhaps we should
 promote this more. I could add backwards compatibility builds to my daily
 build script that uses this in order to check for which kernel versions
 this compiles if there is sufficient interest.
 
  Oh, and users have to git clone 500M+ of data, and not everybody in
  the world has bandwidth fast enough to make that worth their time (it
  took me several hours last time I did it).
 
 Currently the media_build tree copies the drivers from a git tree. Which, as
 you say, can be a big problem for non-developers. But all it really needs are
 the media drivers. So perhaps it might be a good idea to make a daily snapshot
 of the drivers and make it available for download on linuxtv.org. That archive
 is only 3.5 MB, so much easier to download.
 
  Anyway, I've beaten this horse to death and it's fallen on deaf ears.
  Merge overhead has reached the point where it's just not worth my
  time/effort to submit anything upstream anymore.
 
 The hg tree is dead. Douglas Landgraf tried to maintain it, but it's just too
 much work. Any attempt to work from the hg tree is doomed. The media_build
 seems to be a viable alternative. As a developer you still have to go through
 the painful process of cloning the git repo, but it is a one time thing. Once
 it's cloned then you only have to follow the new commits, which is much, much
 faster.
 
 And regarding regressions: I'm amazed how few regressions we have considering
 the furious rate of development. The media subsystem is still one of the most
 active subsystems in the kernel and probably will remain so for the forseeable
 future as well.
 
 It would be a shame not to submit patches upstream, that never ends well in
 the long run.
 
 With respect to '#if 0': for the most part I'd say: good riddance. In my
 many years of experience as a SW engineer I have never seen anyone actually
 turn on '#if 0' code once it's been in the code for more than, say, a year.
 Usually people just leave it there because they are too lazy to remove it,
 or they don't understand what it is for and are too scared to remove it.
 
 If it is code partially implementing a feature that needs more work, then
 it may sound like a good idea to keep it. However, after it's in the code for
 more than a year, then nobody remembers what the code was about and what still
 had to be done to make it work. And it's hell to figure that out after such a
 long time. Never put such code in the mainline. Keep it in a branch if you
 have to.
 
 Anyway, if there is some '#if 0' code that you want to preserve in git, then
 you have to make a patch to add it. But you probably will have to have very
 good reasons for adding '#if 0' code to the mainline.
 
 Regards,
 
   Hans
 --
 To unsubscribe from this list: send the line unsubscribe linux-media in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 

I think you are both right. There, that ought to be pleasing. :-)

More seriously (quoting from above)

 Have you tried Mauro's media_build tree? I had to use it today to test a
 driver from git on a 2.6.35 kernel. Works quite nicely. Perhaps we 
should
 promote this more. 

Probably a

Re: Debug code in HG repositories

2011-01-07 Thread Oliver Endriss 
On Friday 07 January 2011 22:06:30 Hans Verkuil wrote:
 On Friday, January 07, 2011 21:13:31 Devin Heitmueller wrote:
  On Fri, Jan 7, 2011 at 2:53 PM, Oliver Endriss o.endr...@gmx.de wrote:
   Hi guys,
  
   are you aware that there is a lot of '#if 0' code in the HG repositories
   which is not in GIT?
  
   When drivers were submitted to the kernel from HG, the '#if 0' stuff was
   stripped, unless it was marked as 'keep'...
  
   This was fine, when development was done with HG.
  
   As GIT is being used now, that code will be lost, as soon as the HG
   repositories have been removed...
  
   Any opinions how this should be handled?
  
   CU
   Oliver
  
  I complained about this months ago.  The problem is that when we were
  using HG, the HG repo was a complete superset of what went into Git
  (including development/debug code).  But now that we use Git, neither
  is a superset of the other.
  
  If you base your changes on Git, you have to add back in all the
  portability code (and any #if 0 you added as the maintainer for
  development/debugging).  Oh, and regular users cannot test any of your
  changes because they aren't willing to upgrade their entire kernel.
  
  If you base your changes on Hg, nothing merges cleanly when submitted
  upstream so your patches get rejected.
  
  Want to know why we are seeing regressions all over the place?
  Because *NOBODY* is testing the code until after the kernel goes
  stable (since while many are willing to install a v4l-dvb tree, very
  few will are willing to upgrade their entire kernel just to test one
  driver).  We've probably lost about 98% of our user base of testers.
 
 Have you tried Mauro's media_build tree? I had to use it today to test a
 driver from git on a 2.6.35 kernel. Works quite nicely. Perhaps we should
 promote this more. I could add backwards compatibility builds to my daily
 build script that uses this in order to check for which kernel versions
 this compiles if there is sufficient interest.
 
  Oh, and users have to git clone 500M+ of data, and not everybody in
  the world has bandwidth fast enough to make that worth their time (it
  took me several hours last time I did it).
 
 Currently the media_build tree copies the drivers from a git tree. Which, as
 you say, can be a big problem for non-developers. But all it really needs are
 the media drivers. So perhaps it might be a good idea to make a daily snapshot
 of the drivers and make it available for download on linuxtv.org. That archive
 is only 3.5 MB, so much easier to download.
 
  Anyway, I've beaten this horse to death and it's fallen on deaf ears.
  Merge overhead has reached the point where it's just not worth my
  time/effort to submit anything upstream anymore.
 
 The hg tree is dead. Douglas Landgraf tried to maintain it, but it's just too
 much work. Any attempt to work from the hg tree is doomed. The media_build
 seems to be a viable alternative. As a developer you still have to go through
 the painful process of cloning the git repo, but it is a one time thing. Once
 it's cloned then you only have to follow the new commits, which is much, much
 faster.
 
 And regarding regressions: I'm amazed how few regressions we have considering
 the furious rate of development. The media subsystem is still one of the most
 active subsystems in the kernel and probably will remain so for the forseeable
 future as well.

Regressions can be detected only if you have enough testers!

With the current situation, it is very likely that regressions will not
show up before major linux distributions switch to a new kernel.
Afaics the user base is neglectible at the moment. So you can expect
that regressions will show up months after release of a new kernel.

Anyway, this is off-topic. I was not talking about regressions.

 It would be a shame not to submit patches upstream, that never ends well in
 the long run.
 
 With respect to '#if 0': for the most part I'd say: good riddance. In my
 many years of experience as a SW engineer I have never seen anyone actually
 turn on '#if 0' code once it's been in the code for more than, say, a year.
 Usually people just leave it there because they are too lazy to remove it,
 or they don't understand what it is for and are too scared to remove it.
 
 If it is code partially implementing a feature that needs more work, then
 it may sound like a good idea to keep it. However, after it's in the code for
 more than a year, then nobody remembers what the code was about and what still
 had to be done to make it work. And it's hell to figure that out after such a
 long time. Never put such code in the mainline. Keep it in a branch if you
 have to.
 
 Anyway, if there is some '#if 0' code that you want to preserve in git, then
 you have to make a patch to add it. But you probably will have to have very
 good reasons for adding '#if 0' code to the mainline.

I do not care about some #ifdef'ed printk statements.

There are large pieces of driver code which

Re: Debug code in HG repositories

2011-01-07 Thread Vincent McIntyre 
On 1/8/11, Hans Verkuil hverk...@xs4all.nl wrote:

 Have you tried Mauro's media_build tree? I had to use it today to test a
 driver from git on a 2.6.35 kernel. Works quite nicely. Perhaps we should
 promote this more. I could add backwards compatibility builds to my daily
 build script that uses this in order to check for which kernel versions
 this compiles if there is sufficient interest.


As an end-user I would be interested in seeing this added, since it
will allow faster detection of breakage in the older versions. For
instance building against 2.6.32 fails like this:

  CC [M]  /home/vjm/git/clones/linuxtv.org/new_build/v4l/hdpvr-i2c.o
/home/vjm/git/clones/linuxtv.org/new_build/v4l/hdpvr-i2c.c: In
function 'hdpvr_new_i2c_ir':
/home/vjm/git/clones/linuxtv.org/new_build/v4l/hdpvr-i2c.c:62: error:
too many arguments to function 'i2c_new_probed_device'
make[4]: *** [/home/vjm/git/clones/linuxtv.org/new_build/v4l/hdpvr-i2c.o]
Error 1
make[3]: *** [_module_/home/vjm/git/clones/linuxtv.org/new_build/v4l] Error 2
make[3]: Leaving directory `/usr/src/linux-headers-2.6.32-26-ec297b-generic'
make[2]: *** [default] Error 2
make[2]: Leaving directory `/home/vjm/git/clones/linuxtv.org/new_build/v4l'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/home/vjm/git/clones/linuxtv.org/new_build'
make: *** [default] Error 2

It's unclear that adding this would cause a lot of extra work; the
patches that need to be applied are quite few - a tribute to the
design work!

For what it's worth, I've attached the shell script I use to pull
updates and do a new build.
Doing the initial setup is well explained by the
linuxtv.org/media_tree.git page,
but this script may be of use to end users wanting to track development.

Cheers
Vince


update-and-build.sh
Description: Bourne shell script

Re: Debug code in HG repositories

2011-01-07 Thread VDR User 
On Fri, Jan 7, 2011 at 1:06 PM, Hans Verkuil hverk...@xs4all.nl wrote:
 Have you tried Mauro's media_build tree? I had to use it today to test a
 driver from git on a 2.6.35 kernel. Works quite nicely. Perhaps we should
 promote this more. I could add backwards compatibility builds to my daily
 build script that uses this in order to check for which kernel versions
 this compiles if there is sufficient interest.

I'd just like to note that I have been using the media_build daily
snapshots with much success.  IMO, it's about as close as you're going
to get to the old hg system.  As a (mostly) end-user, I am one of the
people unwilling to hassle with the entire git tree (kernel included),
but since the introduction of media_build, we're once again able to
test new code much like we did before.  I strongly urge any end-user
who hasn't given it a try, to do so.

Regards,
Derek
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Debug code in HG repositories

2011-01-07 Thread Jarod Wilson 
On Jan 7, 2011, at 3:13 PM, Devin Heitmueller wrote:

 On Fri, Jan 7, 2011 at 2:53 PM, Oliver Endriss o.endr...@gmx.de wrote:
 Hi guys,
 
 are you aware that there is a lot of '#if 0' code in the HG repositories
 which is not in GIT?
 
 When drivers were submitted to the kernel from HG, the '#if 0' stuff was
 stripped, unless it was marked as 'keep'...
 
 This was fine, when development was done with HG.
 
 As GIT is being used now, that code will be lost, as soon as the HG
 repositories have been removed...
 
 Any opinions how this should be handled?
 
 CU
 Oliver
 
 I complained about this months ago.  The problem is that when we were
 using HG, the HG repo was a complete superset of what went into Git
 (including development/debug code).  But now that we use Git, neither
 is a superset of the other.
 
 If you base your changes on Git, you have to add back in all the
 portability code (and any #if 0 you added as the maintainer for
 development/debugging).  Oh, and regular users cannot test any of your
 changes because they aren't willing to upgrade their entire kernel.
 
 If you base your changes on Hg, nothing merges cleanly when submitted
 upstream so your patches get rejected.
 
 Want to know why we are seeing regressions all over the place?
 Because *NOBODY* is testing the code until after the kernel goes
 stable (since while many are willing to install a v4l-dvb tree, very
 few will are willing to upgrade their entire kernel just to test one
 driver).  We've probably lost about 98% of our user base of testers.

What Hans said re: media_build. I've been pointing quite a few people on
the mythtv-users mailing list in that direction for updated drivers on
top of their distro kernels.

Additionally, the current Fedora 14 kernels (which are 2.6.35.10-based)
carry a patchset developed using media_build with essentially the 2.6.38
rc1 snapshot code, so a fair number of Fedora users *are* testing this
code long before its in a stable upstream kernel release.


-- 
Jarod Wilson
ja...@wilsonet.com



--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html