On Sun, Sep 25, 2011 at 8:33 AM, Patrick Dickey <pdickeybeta@xxxxxxxxx> wrote: > Hello there, > > I tried to follow the steps for cloning both the "media_tree.git" and > "media_build.git" repositories, and received errors for both. The > media_tree repository failed on the first line > >> git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git v4l-dvb > > which I'm assuming is because kernel.org is down. > > The media_build.git repository fails on the first line also > >> git clone git://linuxtv.org/media_build.git > > with a fatal: read error: Connection reset by peer. > > Is it possible to clone either (or both) repositories at this time, or > are they down? And in the absence of cloning the kernel for the > media_tree.git repository, is it possible to simply clone the > git://linuxtv.org/media_tree.git repository and work from that? > > My interest in this is to install some patches created by Devin > Heitmueller for the Pinnacle PCTV 80e USB tuner (at least the ATSC > portion of the tuner). Once I'm able to determine exactly what changes > are made, I would like to either submit the patches to the repository, > or send them to someone who has more experience in patching the files > for submission. > > One other question (totally unrelated to this post though): When I send > emails, normally they are GPG signed. Should I disable that for this > list, or is it acceptable? > > Thank you for any information, and have a great day:) > Patrick. Hi Patrick, As I said on the blog, the issue isn't getting the driver to work against current kernels. Merging the driver against the current tree is a trivial exercise (the patch series should apply trivially against the current code, with only a few minor conflicts related to board numbers, etc). The bigger issue though is once you do that and have the driver running, you now have a body of code > 10,000 lines which doesn't meet the "coding standards". Doing such a refactoring is a relatively straightforward exercise but very time consuming (you already have a working driver, so you just have to make sure you don't break anything). The more I think about this, the more it annoys me. I did all the hard parts: * I worked with the product vendor to get the details for the design * I got Hauppauge/PCTV to compel the chipset vendor to release the reference code under a GPL compatible license * I worked out redistribution terms on the firmware * I ported the driver to Linux * I integrated the driver and debugged it to achieve signal lock And why is it not in the mainline? Because none of the above matters if I didn't waste a bunch of my time removing a bunch of "#ifdef WINDOWS" lines and converting whitespace from tabs to spaces. It's crap like this that's the reason why some of the best LinuxTV driver authors still have a bunch of stuff that isn't merged upstream. We just don't have time for this sort of bullshit that any monkey could do if he/she was willing to invest the effort. We're just too busy doing *actual* driver work. Five years ago the hard part was finding competent developers, getting access to datasheets, getting access to reference driver code, and getting access to the details for a hardware design. Now most of those problems are not the issue - we have access to all the data but we want to waste the time of the few competent developers out there making them do "coding style cleanup" before perfectly good code gets merged upstream. There has been more than one case where I've considered doing a driver for a new board and decided against it because the barrier to getting it upstream is not worth my time. Want to see more device support upstream? Optimize the process to make it easy for the people who know the hardware and how to write the drivers to get code upstream, and leave it to the "janitors" to work out the codingstyle issues. 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
