Re: Improve DKMS build of v4l-dvb?
Op dinsdag 17-03-2009 om 12:50 uur [tijdzone -0700], schreef Trent Piepho: > On Tue, 17 Mar 2009, Alain Kalker wrote: > > Op vrijdag 13-03-2009 om 02:12 uur [tijdzone -0700], schreef Trent > > Piepho: > > > On Mon, 9 Mar 2009, Alain Kalker wrote: > > > > Firstly: generating a .config with just one config variable for the > > > > requested driver set to 'm' merged with the config for the kernel being > > > > built for, and then doing a "make silentoldconfig". Big disatvantage is > > > > that full kernel source is required for the 'silentoldconfig' target to > > > > be available. > > > > > > Does that actually work? Figuring out that needs to be turned on to > > > enable > > > some config options is a hard problem. It's not just simple dependencies > > > between modules, but complex expressions that need to be satisfied. E.g., > > > something "depends on A || B", which do you turn on, A or B? There are > > > multiple solutions so how does the code decide which is best? > > > > Well, make_kconfig.pl does quite a nice job trying to select as many > > drivers without causing conflicts. > > What I did in make_kconfig.pl was just turn everything on, then recursively > disable anything that has a failed dependency. There isn't any > intelligence when it comes to choices where you can have driver set A or > driver set B, but not both. Options that we want disabled, like some > drivers' advanced debug controls, must be explicitly disabled in > make_kconfig. Still, it ends up doing what we want in the end, which is to > compile all the drivers that we can compile. > > > Anyway, you're quite right about this being a hard problem, and the > > fact that the Kconfig system wasn't designed to be very helpful in > > auto-selecting dependencies and resolving conflicts the same way modern > > package managers are, doesn't make it any easier. > > >From what I can tell, solving the dependency problem is easily shown to be > the same as the classical satisfiability problem, which is proven to be NP > complete. Now, there are heuristics that can usually solve SAT problems > quicker but finding the "best" solution quickly is quite a bit harder. Yet, most of us are quite content with the solutions which the dependency resolvers in package managers offer, even if they're possibly non-optimal. Package maintainers try very hard to find ways to ease the dependency problem by supplying acceptable defaults. And like I said before, when no unique solution can be found, the user should have the final say on which solution should be applied. Back to the problem of DKMS builds, I'm not looking for a "perfect" solution for a single driver (neither does make_kconfig.pl look for a "perfect solution for all drivers at once :-) ), I'm looking for a way to reduces the total number of modules that have to be rebuilt when the v4l-dvb source or the kernel is upgraded. How about disabling all modules which don't affect the dependencies of the "target" driver? Attacking the problem from the other side, so to speak. Even when unneccessary modules are still left enabled in the .config, this is still better than building everything but the kitchen sink, which is what the current DKMS script does (it simply does a "make all"). > You don't need write access to the kernel source. The kernel's config > programs have to be built, but that can be done ahead of time. Once they > are, then you can use that menu tool from v4l-dvb without write access to > the kernel source. > > There is support for an alternate output directory for the kernel that can > work too. In the kernel dir, run "make O=~/kernel-output-dir menuconfig". > That should not require write access to the kernel source dir and will put > the necessary config programs in ~/kernel-output-dir. Then point v4l-dvb > at the kernel output dir, with "make release DIR=~/kernel-output-dir". > > See the explanation from my changeset that added this, > http://linuxtv.org/hg/v4l-dvb/log/6331 Good thing I wrote this 17 months > ago when I did the work, instead of just using some two word patch > description, since I sure wouldn't remember how all that works today. Thanks for the info, I will try this. Kind regards, Alain -- 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: Improve DKMS build of v4l-dvb?
On Tue, 17 Mar 2009, Alain Kalker wrote: > Op vrijdag 13-03-2009 om 02:12 uur [tijdzone -0700], schreef Trent > Piepho: > > On Mon, 9 Mar 2009, Alain Kalker wrote: > > > Firstly: generating a .config with just one config variable for the > > > requested driver set to 'm' merged with the config for the kernel being > > > built for, and then doing a "make silentoldconfig". Big disatvantage is > > > that full kernel source is required for the 'silentoldconfig' target to > > > be available. > > > > Does that actually work? Figuring out that needs to be turned on to enable > > some config options is a hard problem. It's not just simple dependencies > > between modules, but complex expressions that need to be satisfied. E.g., > > something "depends on A || B", which do you turn on, A or B? There are > > multiple solutions so how does the code decide which is best? > > Well, make_kconfig.pl does quite a nice job trying to select as many > drivers without causing conflicts. What I did in make_kconfig.pl was just turn everything on, then recursively disable anything that has a failed dependency. There isn't any intelligence when it comes to choices where you can have driver set A or driver set B, but not both. Options that we want disabled, like some drivers' advanced debug controls, must be explicitly disabled in make_kconfig. Still, it ends up doing what we want in the end, which is to compile all the drivers that we can compile. > Anyway, you're quite right about this being a hard problem, and the > fact that the Kconfig system wasn't designed to be very helpful in > auto-selecting dependencies and resolving conflicts the same way modern > package managers are, doesn't make it any easier. >From what I can tell, solving the dependency problem is easily shown to be the same as the classical satisfiability problem, which is proven to be NP complete. Now, there are heuristics that can usually solve SAT problems quicker but finding the "best" solution quickly is quite a bit harder. > For the moment, I would suggest either to choose a default which works > for most people, or ask the user (using any Kconfig menu tool, if only > they didn't need write access to the kernel source, grrr!) to choose > among alternatives if no combination of options can be selected > automatically. You don't need write access to the kernel source. The kernel's config programs have to be built, but that can be done ahead of time. Once they are, then you can use that menu tool from v4l-dvb without write access to the kernel source. There is support for an alternate output directory for the kernel that can work too. In the kernel dir, run "make O=~/kernel-output-dir menuconfig". That should not require write access to the kernel source dir and will put the necessary config programs in ~/kernel-output-dir. Then point v4l-dvb at the kernel output dir, with "make release DIR=~/kernel-output-dir". See the explanation from my changeset that added this, http://linuxtv.org/hg/v4l-dvb/log/6331 Good thing I wrote this 17 months ago when I did the work, instead of just using some two word patch description, since I sure wouldn't remember how all that works today. -- 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: Improve DKMS build of v4l-dvb?
Op vrijdag 13-03-2009 om 02:12 uur [tijdzone -0700], schreef Trent Piepho: > On Mon, 9 Mar 2009, Alain Kalker wrote: > > Martin has an older version of the drivers packaged for building with > > DKMS on Ubuntu in his PPA[5], but it currently has some disadvantages: > > > > A. It builds all available drivers, no matter which hardware is actually > > installed in the system. This takes a lot of time, and may not be > > practical at all on systems with limited resources (e.g. embedded, MIDs, > > netbooks) > > B. It currently has no support for Jockey to detect installed hardware, > > so individual drivers can be selected. > > > > To address these issues, I would like to propose the following: > > > > A. Building individual drivers (i.e. sets of modules which constitute a > > fully-functional driver), without having to manually configure them > > using "make menuconfig" > > > > I see two possibilities for realizing this: > > Firstly: generating a .config with just one config variable for the > > requested driver set to 'm' merged with the config for the kernel being > > built for, and then doing a "make silentoldconfig". Big disatvantage is > > that full kernel source is required for the 'silentoldconfig' target to > > be available. > > Does that actually work? Figuring out that needs to be turned on to enable > some config options is a hard problem. It's not just simple dependencies > between modules, but complex expressions that need to be satisfied. E.g., > something "depends on A || B", which do you turn on, A or B? There are > multiple solutions so how does the code decide which is best? Well, make_kconfig.pl does quite a nice job trying to select as many drivers without causing conflicts. Anyway, you're quite right about this being a hard problem, and the fact that the Kconfig system wasn't designed to be very helpful in auto-selecting dependencies and resolving conflicts the same way modern package managers are, doesn't make it any easier. For the moment, I would suggest either to choose a default which works for most people, or ask the user (using any Kconfig menu tool, if only they didn't need write access to the kernel source, grrr!) to choose among alternatives if no combination of options can be selected automatically. > > Secondly, the script v4l/scripts/analyze_build.pl generates a list of > > modules that will get built for each Kconfig variable selected, but it > > currently has no way of determing all the module dependencies that make > > up a fully functional driver. > > I just wrote analyze_build.pl to make it easier for developers to figure > out that source files make up a module and how to enable it. It's not > actually used by the build system. It's also not perfect when it comes to > parsing makefiles, i.e. it no where near a re-implementation of make's > parser in perl. It understands the typical syntax used by the kernel > makefiles but sometimes there is some unusual bit of make code that it > won't parse. Nice work! I've been using it a lot while testing. I expect to use it also in a tool which will work like 'modinfo', except using module source files as input. I plan to add some nice extensions like showing the config options which enable a module, symbolic DeviceID/VendorID, values, etc. Kind regards, Alain -- 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: Improve DKMS build of v4l-dvb?
On Mon, 9 Mar 2009, Alain Kalker wrote: > Martin has an older version of the drivers packaged for building with > DKMS on Ubuntu in his PPA[5], but it currently has some disadvantages: > > A. It builds all available drivers, no matter which hardware is actually > installed in the system. This takes a lot of time, and may not be > practical at all on systems with limited resources (e.g. embedded, MIDs, > netbooks) > B. It currently has no support for Jockey to detect installed hardware, > so individual drivers can be selected. > > To address these issues, I would like to propose the following: > > A. Building individual drivers (i.e. sets of modules which constitute a > fully-functional driver), without having to manually configure them > using "make menuconfig" > > I see two possibilities for realizing this: > Firstly: generating a .config with just one config variable for the > requested driver set to 'm' merged with the config for the kernel being > built for, and then doing a "make silentoldconfig". Big disatvantage is > that full kernel source is required for the 'silentoldconfig' target to > be available. Does that actually work? Figuring out that needs to be turned on to enable some config options is a hard problem. It's not just simple dependencies between modules, but complex expressions that need to be satisfied. E.g., something "depends on A || B", which do you turn on, A or B? There are multiple solutions so how does the code decide which is best? > Secondly, the script v4l/scripts/analyze_build.pl generates a list of > modules that will get built for each Kconfig variable selected, but it > currently has no way of determing all the module dependencies that make > up a fully functional driver. I just wrote analyze_build.pl to make it easier for developers to figure out that source files make up a module and how to enable it. It's not actually used by the build system. It's also not perfect when it comes to parsing makefiles, i.e. it no where near a re-implementation of make's parser in perl. It understands the typical syntax used by the kernel makefiles but sometimes there is some unusual bit of make code that it won't parse. > The script v4l/scripts/check_deps.pl tries to discover dependencies > between Kconfig variables, but it currently is somewhat slow, and hase a > few other problems. That it is! It's not totally perfect either. Sometimes a driver will only depend on another if something is turned on. But the way check_deps.pl works won't know that. There are also lots of Kconfig variables that don't turn on a module but instead modify what a module does or are used for menus. I think a better system would be use the dependencies in the Kconfig files instead of trying to figure them out from the source. > B. To enable hardware autodetection before installing drivers, we need > to have a list of modaliases of all supported hardware. This may be the > hardest part, because many VendorIDs and ProductIDs are scattered > throughout the code. Also coldbooting/warmbooting hardware is a problem. Extract that from the compiled modules should be easy. -- 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: Improve DKMS build of v4l-dvb?
Op woensdag 11-03-2009 om 10:14 uur [tijdzone -0400], schreef Devin Heitmueller: > I hate to be the one to point this out, but isn't the notion of > automatically rebuilding the modules for *your* hardware broken right > from the start? What this would mean that if I own a laptop and my > USB based capture device happens to not be connected when I upgrade my > kernel, then my drivers are going to be screwed up? Not at all. Hardware detection needs to be done only once: when you first plug in a new device. The result of this detection is then used to generate a dkms.conf file, which specifies exactly which driver needs to be (re-)built. During initial install, and whenever you upgrade your kernel (Whether you have the device plugged in or not), DKMS will (re-)build the driver to match the (current or new) kernel and install its modules on your system. Whenever you plug in your device, the modules making up its driver will get loaded. Kind regards, Alain -- 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: Improve DKMS build of v4l-dvb?
On Wed, Mar 11, 2009 at 7:47 AM, Mauro Carvalho Chehab wrote: >> After the test build, all you have to do is run "modinfo -F alias" on >> all the modules, add the principal module name, and you will end up with >> a modaliases list which is directly usable with Jockey. For users >> without it, another simple script will select the correct principal >> module to build. > > IMO, a perl script searching for PCI and USB tables at the driver would do a > faster job than doing a module build. You don't need to do a test build to > know what modules compile, since v4l/versions.txt already contains the > minimum supported version for each module. If the module is not there, then > it will build since kernel 2.6.16. I hate to be the one to point this out, but isn't the notion of automatically rebuilding the modules for *your* hardware broken right from the start? What this would mean that if I own a laptop and my USB based capture device happens to not be connected when I upgrade my kernel, then my drivers are going to be screwed up? Maybe I'm just missing something. Devin -- Devin J. Heitmueller http://www.devinheitmueller.com AIM: devinheitmueller -- 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: Improve DKMS build of v4l-dvb?
Op woensdag 11-03-2009 om 08:47 uur [tijdzone -0300], schreef Mauro Carvalho Chehab: > IMO, a perl script searching for PCI and USB tables at the driver > would do > a faster job than doing a module build. You don't need to do a test build > to know what modules compile, since v4l/versions.txt already contains the > minimum supported version for each module. If the module is not there, > then it will build since kernel 2.6.16. Good point, but for now I'm staying away from parsing the source files (tough job to get it right with all the substitutions and the like), so I can finish up packaging the source for DKMS and building the right modules for a driver. Kind regards, Alain -- 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: Improve DKMS build of v4l-dvb?
Op woensdag 11-03-2009 om 12:36 uur [tijdzone +0100], schreef Alain Kalker: > Very true. I'm quite dissatisfied with the sad state that Kbuild support > for building external modules in the mainline kernel is in. I'm actually considering asking the linux-kbuild list how this can be improved, When (DKMS) and on-demand driver building gain more popularity, something _has_ to change... > Kind regards, > > Alain -- 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: Improve DKMS build of v4l-dvb?
On Wed, 11 Mar 2009, Alain Kalker wrote: Op maandag 09-03-2009 om 20:43 uur [tijdzone -0300], schreef Mauro Carvalho Chehab: It is not that hard. You'll have a few vars that will always have the same values, like: [snip] Thanks for the information, I'll use this as a starting point. Of course, you'll need to write some script to identify what devices are available at the host (by USB or PCI ID), and associate it with the V4L/DVB drivers. Scanning for available hardware is already available in Jockey, and parsing the output from 'lsusb'/'lspci' will do it for users without it. Associating IDs with the principal module is easy after doing a test build of all modules (which needs to be done anyway, to find out which drivers can actually be built with the current tree and to decide whether the tree is suitable for packaging for DKMS build). After the test build, all you have to do is run "modinfo -F alias" on all the modules, add the principal module name, and you will end up with a modaliases list which is directly usable with Jockey. For users without it, another simple script will select the correct principal module to build. IMO, a perl script searching for PCI and USB tables at the driver would do a faster job than doing a module build. You don't need to do a test build to know what modules compile, since v4l/versions.txt already contains the minimum supported version for each module. If the module is not there, then it will build since kernel 2.6.16. All that remains then is to sort out the module dependencies... Probably, the hardest part is to maintain, so, ideally, the scripts should scan the source codes to check what drivers you have, and what are the driver options associated with that device. Very true. I'm quite dissatisfied with the sad state that Kbuild support for building external modules is in, especially for projects that have numerous drivers and module dependencies, and I believe v4l-dvb has currently the most advanced out-of-tree support available. Thanks! If you enjoy watching a horror movie, have a look at the drivers from the ALSA project, they have a hideous 131615 bytes big beast hidden in their aclocal.m4, whose sole purpose it is to sort out config variable dependencies... Yuck! Yeah, I've seen this already. 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: Improve DKMS build of v4l-dvb?
Op maandag 09-03-2009 om 20:43 uur [tijdzone -0300], schreef Mauro Carvalho Chehab: > It is not that hard. You'll have a few vars that will always have the same > values, like: [snip] Thanks for the information, I'll use this as a starting point. > Of course, you'll need to write some script to identify what devices are > available at the host (by USB or PCI ID), and associate it with the V4L/DVB > drivers. Scanning for available hardware is already available in Jockey, and parsing the output from 'lsusb'/'lspci' will do it for users without it. Associating IDs with the principal module is easy after doing a test build of all modules (which needs to be done anyway, to find out which drivers can actually be built with the current tree and to decide whether the tree is suitable for packaging for DKMS build). After the test build, all you have to do is run "modinfo -F alias" on all the modules, add the principal module name, and you will end up with a modaliases list which is directly usable with Jockey. For users without it, another simple script will select the correct principal module to build. All that remains then is to sort out the module dependencies... > Probably, the hardest part is to maintain, so, ideally, the scripts should > scan > the source codes to check what drivers you have, and what are the driver > options associated with that device. Very true. I'm quite dissatisfied with the sad state that Kbuild support for building external modules is in, especially for projects that have numerous drivers and module dependencies, and I believe v4l-dvb has currently the most advanced out-of-tree support available. If you enjoy watching a horror movie, have a look at the drivers from the ALSA project, they have a hideous 131615 bytes big beast hidden in their aclocal.m4, whose sole purpose it is to sort out config variable dependencies... Yuck! > If you can write such script, then we can add it at v4l/scripts and add a > "make myconfig" option that would run the script and compile the minimal set > of > drivers. That would be great! Kind regards, Alain -- 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: Improve DKMS build of v4l-dvb?
On Mon, 09 Mar 2009 16:34:54 +0100 Alain Kalker wrote: > I'm interested in improving the very interesting work[1] by Martin > Pitt[2] on making the v4l-dvb tree build under DKMS[3], so the drivers > get automatically rebuilt when the user installs a new kernel package. > > Martin also works on the Jockey driver manager[4] which is used in > Ubuntu to detect hardware for which there are no drivers in the kernel > and to inform the user about available driver packages which can then be > downloaded and installed automatically. > > Enabling DKMS build of v4l-dvb will also enable users with no experience > in building kernel modules to easily install the latest development > drivers for their hardware. This will improve the exposure of v4l-dvb > drivers to a wider community of users who can help with testing the > drivers on the wide variety of hardware that is out there. > > Martin has an older version of the drivers packaged for building with > DKMS on Ubuntu in his PPA[5], but it currently has some disadvantages: > > A. It builds all available drivers, no matter which hardware is actually > installed in the system. This takes a lot of time, and may not be > practical at all on systems with limited resources (e.g. embedded, MIDs, > netbooks) > B. It currently has no support for Jockey to detect installed hardware, > so individual drivers can be selected. > > To address these issues, I would like to propose the following: > > A. Building individual drivers (i.e. sets of modules which constitute a > fully-functional driver), without having to manually configure them > using "make menuconfig" > > I see two possibilities for realizing this: > Firstly: generating a .config with just one config variable for the > requested driver set to 'm' merged with the config for the kernel being > built for, and then doing a "make silentoldconfig". Big disatvantage is > that full kernel source is required for the 'silentoldconfig' target to > be available. > Secondly, the script v4l/scripts/analyze_build.pl generates a list of > modules that will get built for each Kconfig variable selected, but it > currently has no way of determing all the module dependencies that make > up a fully functional driver. > The script v4l/scripts/check_deps.pl tries to discover dependencies > between Kconfig variables, but it currently is somewhat slow, and hase a > few other problems. > > B. To enable hardware autodetection before installing drivers, we need > to have a list of modaliases of all supported hardware. This may be the > hardest part, because many VendorIDs and ProductIDs are scattered > throughout the code. Also coldbooting/warmbooting hardware is a problem. > > I am very interested in any comments on these ideas, and getting in > contact with anyone who would like to help me with this project. It is not that hard. You'll have a few vars that will always have the same values, like: CONFIG_VIDEO_DEV=m CONFIG_VIDEO_V4L2_COMMON=m CONFIG_VIDEO_ALLOW_V4L1=y CONFIG_VIDEO_V4L1_COMPAT=y CONFIG_DVB_CORE=m CONFIG_VIDEO_MEDIA=m CONFIG_MEDIA_ATTACH=y CONFIG_VIDEO_CAPTURE_DRIVERS=y CONFIG_VIDEO_HELPER_CHIPS_AUTO=y CONFIG_V4L_USB_DRIVERS=y CONFIG_USB_GSPCA=m CONFIG_RADIO_ADAPTERS=y CONFIG_DVB_DYNAMIC_MINORS=y CONFIG_DVB_CAPTURE_DRIVERS=y CONFIG_MEDIA_TUNER=m CONFIG_VIDEO_V4L2=m CONFIG_VIDEO_V4L1=m CONFIG_VIDEO_CAPTURE_DRIVERS=y CONFIG_V4L_USB_DRIVERS=y CONFIG_USB_GSPCA=m CONFIG_RADIO_ADAPTERS=y CONFIG_DVB_DYNAMIC_MINORS=y CONFIG_DVB_CAPTURE_DRIVERS=y # CONFIG_DAB is not set You should also be sure that the helper chips will be auto-selected, with those three options: CONFIG_VIDEO_HELPER_CHIPS_AUTO=y # MEDIA_TUNER_CUSTOMIZE is not set # CONFIG_DVB_FE_CUSTOMISE is not set Then, all you need, in order to support an specific board is to add the driver-specific Kconfig, like (for cx88): CONFIG_VIDEO_CX88=m CONFIG_VIDEO_CX88_ALSA=m CONFIG_VIDEO_CX88_BLACKBIRD=m CONFIG_VIDEO_CX88_DVB=m CONFIG_VIDEO_CX88_MPEG=m CONFIG_VIDEO_CX88_VP3054=m Of course, you'll need to write some script to identify what devices are available at the host (by USB or PCI ID), and associate it with the V4L/DVB drivers. Probably, the hardest part is to maintain, so, ideally, the scripts should scan the source codes to check what drivers you have, and what are the driver options associated with that device. If you can write such script, then we can add it at v4l/scripts and add a "make myconfig" option that would run the script and compile the minimal set of drivers. > > Kind regards, > > Alain > > [1] > http://martinpitt.wordpress.com/2008/06/10/packaged-dvb-t-drivers-for-ubuntu-804/ > [2] https://launchpad.net/~pitti > [3] http://linux.dell.com/projects.shtml#dkms > [4] https://launchpad.net/jockey > [5] https://launchpad.net/~pitti/+archive/ppa > > -- > 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 Ch
Improve DKMS build of v4l-dvb?
I'm interested in improving the very interesting work[1] by Martin Pitt[2] on making the v4l-dvb tree build under DKMS[3], so the drivers get automatically rebuilt when the user installs a new kernel package. Martin also works on the Jockey driver manager[4] which is used in Ubuntu to detect hardware for which there are no drivers in the kernel and to inform the user about available driver packages which can then be downloaded and installed automatically. Enabling DKMS build of v4l-dvb will also enable users with no experience in building kernel modules to easily install the latest development drivers for their hardware. This will improve the exposure of v4l-dvb drivers to a wider community of users who can help with testing the drivers on the wide variety of hardware that is out there. Martin has an older version of the drivers packaged for building with DKMS on Ubuntu in his PPA[5], but it currently has some disadvantages: A. It builds all available drivers, no matter which hardware is actually installed in the system. This takes a lot of time, and may not be practical at all on systems with limited resources (e.g. embedded, MIDs, netbooks) B. It currently has no support for Jockey to detect installed hardware, so individual drivers can be selected. To address these issues, I would like to propose the following: A. Building individual drivers (i.e. sets of modules which constitute a fully-functional driver), without having to manually configure them using "make menuconfig" I see two possibilities for realizing this: Firstly: generating a .config with just one config variable for the requested driver set to 'm' merged with the config for the kernel being built for, and then doing a "make silentoldconfig". Big disatvantage is that full kernel source is required for the 'silentoldconfig' target to be available. Secondly, the script v4l/scripts/analyze_build.pl generates a list of modules that will get built for each Kconfig variable selected, but it currently has no way of determing all the module dependencies that make up a fully functional driver. The script v4l/scripts/check_deps.pl tries to discover dependencies between Kconfig variables, but it currently is somewhat slow, and hase a few other problems. B. To enable hardware autodetection before installing drivers, we need to have a list of modaliases of all supported hardware. This may be the hardest part, because many VendorIDs and ProductIDs are scattered throughout the code. Also coldbooting/warmbooting hardware is a problem. I am very interested in any comments on these ideas, and getting in contact with anyone who would like to help me with this project. Kind regards, Alain [1] http://martinpitt.wordpress.com/2008/06/10/packaged-dvb-t-drivers-for-ubuntu-804/ [2] https://launchpad.net/~pitti [3] http://linux.dell.com/projects.shtml#dkms [4] https://launchpad.net/jockey [5] https://launchpad.net/~pitti/+archive/ppa -- 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
