| Message ID | 1237467800.19717.37.camel@tux.localhost (mailing list archive) |
|---|---|
| State | Rejected |
| Headers | show |
On Thu, 19 Mar 2009 16:03:20 +0300 Alexey Klimov <klimov.linux@gmail.com> wrote: > Hello, all > What do you think about such patch that makes selecting of radio drivers > in menuconfig more comfortable ? Frankly, I don't see any gain: If the user doesn't have ISA (or doesn't want to have), it should have already unselected the ISA sub-menu. The remaining PCI and USB drivers are few. So, creating menus for them seem overkill. We could eventually reorganize the item order, and adding a few comments to indicate the drivers that are ISA, PCI, PCIe and USB (something similar to what was done at DVB frontend part of the menu), but still, I can't see much value. Cheers, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Mar 19, 2009 at 5:03 PM, Mauro Carvalho Chehab <mchehab@infradead.org> wrote: > On Thu, 19 Mar 2009 16:03:20 +0300 > Alexey Klimov <klimov.linux@gmail.com> wrote: > >> Hello, all >> What do you think about such patch that makes selecting of radio drivers >> in menuconfig more comfortable ? > > Frankly, I don't see any gain: If the user doesn't have ISA (or doesn't want to > have), it should have already unselected the ISA sub-menu. The remaining PCI > and USB drivers are few. So, creating menus for them seem overkill. > > We could eventually reorganize the item order, and adding a few comments to > indicate the drivers that are ISA, PCI, PCIe and USB (something similar to what > was done at DVB frontend part of the menu), but still, I can't see much value. Okay, well, sorry for bothering. Only one point here - if user want to unselect radio drivers in menuconfig, for example - pci and isa in some bad config file he should pick a lot of times, and with this patch only 2 times. But, okay.
On Thu, 19 Mar 2009 17:18:47 +0300 Alexey Klimov <klimov.linux@gmail.com> wrote: > On Thu, Mar 19, 2009 at 5:03 PM, Mauro Carvalho Chehab > <mchehab@infradead.org> wrote: > > On Thu, 19 Mar 2009 16:03:20 +0300 > > Alexey Klimov <klimov.linux@gmail.com> wrote: > > > >> Hello, all > >> What do you think about such patch that makes selecting of radio drivers > >> in menuconfig more comfortable ? > > > > Frankly, I don't see any gain: If the user doesn't have ISA (or doesn't want to > > have), it should have already unselected the ISA sub-menu. The remaining PCI > > and USB drivers are few. So, creating menus for them seem overkill. > > > > We could eventually reorganize the item order, and adding a few comments to > > indicate the drivers that are ISA, PCI, PCIe and USB (something similar to what > > was done at DVB frontend part of the menu), but still, I can't see much value. > > Okay, well, sorry for bothering. > Only one point here - if user want to unselect radio drivers in > menuconfig, for example - pci and isa in some bad config file he > should pick a lot of times, and with this patch only 2 times. > But, okay. > Once, someone suggested me to create some sort of "default" option for media drivers, in a way that people can just click on a few places, if he wants to do things like "select all that compiles and their dependencies" or "don't select nothing" except for those. Those kind of things could be interesting, but they may create even more mess over what we currently have on our complex Kbuilding system. For the out-of-system building, one alternative would be to create some make syntax for building just some drivers, like: make driver=cx88,ivtv or, even better: make cx88 ivtv Such command could generate a .config file that has just the driver plus their dependencies and selects. Cheers, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, 19 Mar 2009, Mauro Carvalho Chehab wrote: > On Thu, 19 Mar 2009 17:18:47 +0300 > Alexey Klimov <klimov.linux@gmail.com> wrote: > over what we currently have on our complex Kbuilding system. > > For the out-of-system building, one alternative would be to create some make > syntax for building just some drivers, like: > > make driver=cx88,ivtv The problem with this is that it's really hard to do decently. For instance, if you want cx88 dvb support, you need some front-ends to do anything with it. Well, what front-ends should be turned on? You can turn on any number from none to all. Probably all of them would be best. But there are tons of other tuners, front-ends, decoders, drivers, etc. that cx88 doesn't use. Those should be off. So you give an algorithm the config variables you want set (e.g., VIDEO_CX88) and then tell it to find a valid solution to the rest of the variables given the constraints from Kconfig. This is the classic NP-complete SAT problem. It is hard, but we can solve this. But we get a solution that has all the tuners, etc. that cx88 can't used turned on. That's not what we want! So, we say we want the solution that has the fewest modules turned on. Well, you've just made the problem much much harder to solve as SAT solving heuristics won't do you any good now. But suppose we solve it anyway and get the solution with the fewest modules turned on. It's going to have all the frontends cx88 can use turned OFF. That's not what we want either! How is the algorithm supposed to know what we want on and what we want off? We basically have to do it so that 'make cx88' means use certain exact config options that someone has manually pre-configured. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, 19 Mar 2009 15:43:42 -0700 (PDT) Trent Piepho <xyzzy@speakeasy.org> wrote: > On Thu, 19 Mar 2009, Mauro Carvalho Chehab wrote: > > On Thu, 19 Mar 2009 17:18:47 +0300 > > Alexey Klimov <klimov.linux@gmail.com> wrote: > > over what we currently have on our complex Kbuilding system. > > > > For the out-of-system building, one alternative would be to create some make > > syntax for building just some drivers, like: > > > > make driver=cx88,ivtv > > The problem with this is that it's really hard to do decently. True. > For instance, if you want cx88 dvb support, you need some front-ends to do > anything with it. Well, what front-ends should be turned on? You can turn > on any number from none to all. Probably all of them would be best. But > there are tons of other tuners, front-ends, decoders, drivers, etc. that > cx88 doesn't use. Those should be off. > > So you give an algorithm the config variables you want set (e.g., > VIDEO_CX88) and then tell it to find a valid solution to the rest of the > variables given the constraints from Kconfig. This is the classic > NP-complete SAT problem. It is hard, but we can solve this. > > But we get a solution that has all the tuners, etc. that cx88 can't used > turned on. That's not what we want! So, we say we want the solution that > has the fewest modules turned on. Well, you've just made the problem much > much harder to solve as SAT solving heuristics won't do you any good now. > > But suppose we solve it anyway and get the solution with the fewest modules > turned on. It's going to have all the frontends cx88 can use turned OFF. > That's not what we want either! How is the algorithm supposed to know what > we want on and what we want off? We basically have to do it so that 'make > cx88' means use certain exact config options that someone has manually > pre-configured. It is hard to have a tool that will truly compile just the minimum amount of things that the user needs. Yet, it seems valid to have a make to select some specific subsets. For example, we may select the the "common" configs, like: CONFIG_VIDEO_DEV=y CONFIG_VIDEO_V4L2_COMMON=m CONFIG_VIDEO_ALLOW_V4L1=y CONFIG_VIDEO_V4L1_COMPAT=y CONFIG_DVB_CORE=y CONFIG_VIDEO_MEDIA=y CONFIG_DVB_DYNAMIC_MINORS=y (we need to add here also the menu-only group of configs) And allowing the automation of the helper chips: CONFIG_VIDEO_HELPER_CHIPS_AUTO=y # CONFIG_MEDIA_TUNER_CUSTOMISE is not set # CONFIG_DVB_FE_CUSTOMISE is not set Then, the make will add just the modules for that specific driver. In the case of cx88, an interesting subset would be to select 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 For sure this is _not_ the minimal set of cx88. People may not want blackbird, or their device may not need xc5000, for example. Yet, it is faster to compile the above 42 kernel modules than all the 200+ modules of a full build. The advantages are bigger if we think on those smaller drivers, like for example opera1: CONFIG_DVB_USB_OPERA1=m Such config will compile only 15 drivers: LD [M] /home/v4l/master/v4l/dvb-usb-opera.ko LD [M] /home/v4l/master/v4l/dvb-usb.ko LD [M] /home/v4l/master/v4l/tea5767.ko LD [M] /home/v4l/master/v4l/stv0299.ko LD [M] /home/v4l/master/v4l/dvb-pll.ko LD [M] /home/v4l/master/v4l/mt20xx.ko LD [M] /home/v4l/master/v4l/mc44s803.ko LD [M] /home/v4l/master/v4l/xc5000.ko LD [M] /home/v4l/master/v4l/tuner-simple.ko LD [M] /home/v4l/master/v4l/tuner-types.ko LD [M] /home/v4l/master/v4l/tda8290.ko LD [M] /home/v4l/master/v4l/v4l2-common.ko LD [M] /home/v4l/master/v4l/tea5761.ko LD [M] /home/v4l/master/v4l/tuner-xc2028.ko LD [M] /home/v4l/master/v4l/tda9887.ko Cheers, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Op donderdag 19-03-2009 om 15:43 uur [tijdzone -0700], schreef Trent Piepho: > On Thu, 19 Mar 2009, Mauro Carvalho Chehab wrote: > > On Thu, 19 Mar 2009 17:18:47 +0300 > > Alexey Klimov <klimov.linux@gmail.com> wrote: > > over what we currently have on our complex Kbuilding system. > > > > For the out-of-system building, one alternative would be to create some make > > syntax for building just some drivers, like: > > > > make driver=cx88,ivtv > > The problem with this is that it's really hard to do decently. It depends on how you define 'decently'. We're not trying to find a general solution to the Boolean Satisfiability Problem here, we can use information about the structure of the dependencies to simplify. As I see it, drivers depend on subsystems, which in turn depend on core functionality. These are mandatory dependencies: an USB device won't function without USB support. Then there are recommended and optional dependencies, which enhance the functionality of a driver. As I have seen with the dummy frontend module, a driver doesn't need to _have_ a frontend module to be functional (e.g. if there simply isn't one written yet), it just will be (much) less useful. Pruning (deselecting) all principal modules (i.e. those that actually provide modaliases) for devices that we don't want, and then pruning all of their dependencies that have now become redundant (i.e. modules that have nothing or only unselected modules depending on them) seems decent enough to me. > For instance, if you want cx88 dvb support, you need some front-ends to do > anything with it. Well, what front-ends should be turned on? You can turn > on any number from none to all. Probably all of them would be best. But > there are tons of other tuners, front-ends, decoders, drivers, etc. that > cx88 doesn't use. Those should be off. This is already covered by DVB_FE_CUSTOMIZE. A user who just wants a driver for his device and doesn't know (or care) what frontend it uses, can just supply a target config of: CONFIG_DVB_FE_CUSTOMISE=n CONFIG_<driver>=m and build the driver, which should simply build all available frontend modules. This already happens with allmodconfig, and as far as I know, the current drivers don't care if one or many frontent modules are available, the right one to use will be selected during hardware probe/attach depending on the actual hardware anyway. A user who wants to further customise the frontend(s) used with the driver, should supply this information: DVB_FE_CUSTOMISE=y CONFIG_<driver>=m CONFIG_<frontend>=M ... This looks very much like the 'virtual packages' and 'alternatives' support in package managers. > So you give an algorithm the config variables you want set (e.g., > VIDEO_CX88) and then tell it to find a valid solution to the rest of the > variables given the constraints from Kconfig. This is the classic > NP-complete SAT problem. It is hard, but we can solve this. By redefining dependencies and restructuring the dependency graph so requirements can be propagated better, you can greatly reduce this problem, to the point that simple search, backtracking or heuristics become quite feasible. Again, package managers are a good example. Entire Linux installers, live cds and preconfigured embedded systems are being generated with very little user intervention on a daily basis. Kind regards, Alain -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Op zaterdag 21-03-2009 om 22:11 uur [tijdzone +0100], schreef Alain Kalker: > Op donderdag 19-03-2009 om 15:43 uur [tijdzone -0700], schreef Trent > Piepho: > > On Thu, 19 Mar 2009, Mauro Carvalho Chehab wrote: > > > On Thu, 19 Mar 2009 17:18:47 +0300 > > > Alexey Klimov <klimov.linux@gmail.com> wrote: > > > over what we currently have on our complex Kbuilding system. > > > > > > For the out-of-system building, one alternative would be to create some make > > > syntax for building just some drivers, like: > > > > > > make driver=cx88,ivtv > > > > The problem with this is that it's really hard to do decently. > > It depends on how you define 'decently'. We're not trying to find a > general solution to the Boolean Satisfiability Problem here, we can use > information about the structure of the dependencies to simplify. > As I see it, drivers depend on subsystems, which in turn depend on core > functionality. These are mandatory dependencies: an USB device won't > function without USB support. > Then there are recommended and optional dependencies, which enhance the > functionality of a driver. As I have seen with the dummy frontend > module, a driver doesn't need to _have_ a frontend module to be > functional (e.g. if there simply isn't one written yet), it just will be > (much) less useful. Also, I believe there are very few (if any) circular, multiple or conflicting dependencies in the tree. All this structural information can be used to ease tackling this problem. > Pruning (deselecting) all principal modules (i.e. those that actually > provide modaliases) for devices that we don't want, and then pruning all > of their dependencies that have now become redundant (i.e. modules that > have nothing or only unselected modules depending on them) seems decent > enough to me. > Kind regards, > > Alain -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Op zaterdag 21-03-2009 om 22:16 uur [tijdzone +0100], schreef Alain Kalker: Starting out from 'allmodconfig', > > Pruning (deselecting) all principal modules (i.e. those that actually > > provide modaliases) for devices that we don't want, and then pruning all > > of their dependencies that have now become redundant (i.e. modules that > > have nothing or only unselected modules depending on them) seems decent > > enough to me. Sorry for the multiple refinement replies :-) > > Kind regards, > > > > Alain -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff -r 626c136ec221 linux/drivers/media/radio/Kconfig --- a/linux/drivers/media/radio/Kconfig Fri Mar 13 14:35:14 2009 -0700 +++ b/linux/drivers/media/radio/Kconfig Thu Mar 19 15:20:12 2009 +0300 @@ -10,6 +10,13 @@ Say Y here to enable selecting AM/FM radio adapters. if RADIO_ADAPTERS && VIDEO_V4L2 + +config RADIO_ADAPTERS_ISA + boolean "ISA radio adapters" + ---help--- + Enable this if you have ISA-based radio adapter. + +if RADIO_ADAPTERS_ISA config RADIO_CADET tristate "ADS Cadet AM/FM Tuner" @@ -150,50 +157,6 @@ Say Y here to enable automatic probing for GemTek Radio card. The following ports will be probed: 0x20c, 0x30c, 0x24c, 0x34c, 0x248 and 0x28c. - -config RADIO_GEMTEK_PCI - tristate "GemTek PCI Radio Card support" - depends on VIDEO_V4L2 && PCI - ---help--- - Choose Y here if you have this PCI FM radio card. - - In order to control your radio card, you will need to use programs - that are compatible with the Video for Linux API. Information on - this API and pointers to "v4l" programs may be found at - <file:Documentation/video4linux/API.html>. - - To compile this driver as a module, choose M here: the - module will be called radio-gemtek-pci. - -config RADIO_MAXIRADIO - tristate "Guillemot MAXI Radio FM 2000 radio" - depends on VIDEO_V4L2 && PCI - ---help--- - Choose Y here if you have this radio card. This card may also be - found as Gemtek PCI FM. - - In order to control your radio card, you will need to use programs - that are compatible with the Video For Linux API. Information on - this API and pointers to "v4l" programs may be found at - <file:Documentation/video4linux/API.html>. - - To compile this driver as a module, choose M here: the - module will be called radio-maxiradio. - -config RADIO_MAESTRO - tristate "Maestro on board radio" - depends on VIDEO_V4L2 && PCI - ---help--- - Say Y here to directly support the on-board radio tuner on the - Maestro 2 or 2E sound card. - - In order to control your radio card, you will need to use programs - that are compatible with the Video For Linux API. Information on - this API and pointers to "v4l" programs may be found at - <file:Documentation/video4linux/API.html>. - - To compile this driver as a module, choose M here: the - module will be called radio-maestro. config RADIO_SF16FMI tristate "SF16FMI Radio" @@ -339,6 +302,68 @@ help Enter the I/O port of your Zoltrix radio card. +endif # RADIO_ADAPTERS_ISA + +config RADIO_ADAPTERS_PCI + boolean "PCI radio adapters" + ---help--- + Enable this if you have PCI-based radio adapters. + +if RADIO_ADAPTERS_PCI + +config RADIO_GEMTEK_PCI + tristate "GemTek PCI Radio Card support" + depends on VIDEO_V4L2 && PCI + ---help--- + Choose Y here if you have this PCI FM radio card. + + In order to control your radio card, you will need to use programs + that are compatible with the Video for Linux API. Information on + this API and pointers to "v4l" programs may be found at + <file:Documentation/video4linux/API.html>. + + To compile this driver as a module, choose M here: the + module will be called radio-gemtek-pci. + +config RADIO_MAXIRADIO + tristate "Guillemot MAXI Radio FM 2000 radio" + depends on VIDEO_V4L2 && PCI + ---help--- + Choose Y here if you have this radio card. This card may also be + found as Gemtek PCI FM. + + In order to control your radio card, you will need to use programs + that are compatible with the Video For Linux API. Information on + this API and pointers to "v4l" programs may be found at + <file:Documentation/video4linux/API.html>. + + To compile this driver as a module, choose M here: the + module will be called radio-maxiradio. + +config RADIO_MAESTRO + tristate "Maestro on board radio" + depends on VIDEO_V4L2 && PCI + ---help--- + Say Y here to directly support the on-board radio tuner on the + Maestro 2 or 2E sound card. + + In order to control your radio card, you will need to use programs + that are compatible with the Video For Linux API. Information on + this API and pointers to "v4l" programs may be found at + <file:Documentation/video4linux/API.html>. + + To compile this driver as a module, choose M here: the + module will be called radio-maestro. + +endif # RADIO_ADAPTERS_PCI + +config RADIO_ADAPTERS_OTHERS + boolean "USB, I2C and others radio adapter interfaces" + ---help--- + Enable this if you have USB, I2C or others radio interfaces. + +if RADIO_ADAPTERS_OTHERS + config USB_DSBR tristate "D-Link/GemTek USB FM radio support" depends on USB && VIDEO_V4L2 @@ -406,4 +431,6 @@ Say Y here if TEA5764 have a 32768 Hz crystal in circuit, say N here if TEA5764 reference frequency is connected in FREQIN. +endif # RADIO_ADAPTERS_OTHERS + endif # RADIO_ADAPTERS
Hello, all What do you think about such patch that makes selecting of radio drivers in menuconfig more comfortable ? --- Patch divides/separates radio drivers in Kconfig in 3 groups - ISA, PCI and others. Signed-off-by: Alexey Klimov <klimov.linux@gmail.com> --