[kbuild-devel] Re: [patch] kernel config 3/N - move sound into drivers/media
On Tue, Aug 13, 2002 at 11:35:58PM -0500, Peter Samuelson wrote: The big loser here is ARM - it no longer suppresses the sound card question for the appropriate boards. But it's just one question, so I didn't sweat it too much. I'd be tempted to drop that set of tests, and just rely on the per-driver stuff, where its sane to do so. There's no way we can special case all the drivers out there for each machine type in the generic config files. That is the route to madness. -- Russell King ([EMAIL PROTECTED])The developer of ARM Linux http://www.arm.linux.org.uk/personal/aboutme.html --- This sf.net email is sponsored by: Dice - The leading online job board for high-tech professionals. Search and apply for tech jobs today! http://seeker.dice.com/seeker.epl?rel_code=31 ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Re: [patch] kernel config 3/N - move sound into drivers/media
On Wednesday 14 August 2002 07:49, Peter Samuelson wrote: [Kai Germaschewski] It comes of the cost of testing for the architecture, since e.g. s390 does not want to include most of drivers/*, but that means we'd actually collect this knowledge at a centralized place. What we need is an easy way to check for any arch. CONFIG_ARCH_S390 is the right idea (though s390x sets it as well, not sure if that's good or bad). It's not logical, but it tends to help because it's what's meant most of the time. I don't know a single place in the kernel where you want to test for (CONFIG_ARCH_S390 !CONFIG_ARCH_S390X). Rather than making everything depend on CONFIG_ARCH_THIS CONFIG_ARCH_THAT, I'd prefer if every driver depended on its bus type. With the new driver model, every driver has a clearly defined bus type and driver class, so it would be logical to have that driver option exactly when these two are enabled. Of course, that probably means a huge amount of work but it helps avoid problems when a new architecture is added or an existing one gets a new bus. E.g., s390 used to have no support for SCSI, but with the zfcp driver we enable drivers/scsi/Config.in, so now we get a lot of questions about drivers that won't work. Enclosing the drivers in CONFIG_ARCH_s390 != y does help us, but it would still be wrong to do that for a Sparc kernel that supports some of the PCI cards but not the ISA ones. Arnd --- This sf.net email is sponsored by: Dice - The leading online job board for high-tech professionals. Search and apply for tech jobs today! http://seeker.dice.com/seeker.epl?rel_code=31 ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: [patch] kernel config 3/N - move sound into drivers/media
On Wed, 14 Aug 2002, Greg Banks wrote: @@ -330,6 +329,5 @@ 1 CONFIG_ZORRO -34 forward-dependancy +23 forward-dependancy 11 CONFIG_ISDN_CAPI 11 CONFIG_PROC_FS -11 CONFIG_SOUND_ACI_MIXER 1 CONFIG_BLK_DEV_SD Could you check that the appended patch solves the CONFIG_ISDN_CAPI problem (and doesn't introduce new ones)? --Kai = drivers/isdn/Config.in 1.18 vs edited = --- 1.18/drivers/isdn/Config.in Wed Apr 24 09:42:33 2002 +++ edited/drivers/isdn/Config.in Wed Aug 14 10:49:07 2002 @@ -22,8 +22,9 @@ tristate 'CAPI2.0 support' CONFIG_ISDN_CAPI if [ $CONFIG_ISDN_CAPI != n ]; then source drivers/isdn/capi/Config.in - source drivers/isdn/hardware/Config.in fi + + source drivers/isdn/hardware/Config.in fi fi endmenu = drivers/isdn/hardware/Config.in 1.1 vs edited = --- 1.1/drivers/isdn/hardware/Config.in Sun Apr 21 23:07:44 2002 +++ edited/drivers/isdn/hardware/Config.in Wed Aug 14 11:01:04 2002 @@ -2,4 +2,26 @@ # ISDN hardware drivers # -source drivers/isdn/hardware/avm/Config.in +if [ $CONFIG_ISDN_CAPI != n ]; then + comment 'CAPI hardware drivers' + source drivers/isdn/hardware/avm/Config.in +fi + +if [ $CONFIG_ISDN != n ]; then + comment 'ISDN4Linux hardware drivers' + + source drivers/isdn/hisax/Config.in + + mainmenu_option next_comment + comment 'Active cards' + + source drivers/isdn/icn/Config.in + source drivers/isdn/pcbit/Config.in + source drivers/isdn/sc/Config.in + source drivers/isdn/act2000/Config.in + source drivers/isdn/eicon/Config.in + source drivers/isdn/tpam/Config.in + source drivers/isdn/hysdn/Config.in + endmenu +fi + = drivers/isdn/hardware/avm/Config.in 1.3 vs edited = --- 1.3/drivers/isdn/hardware/avm/Config.in Tue Jun 18 14:00:47 2002 +++ edited/drivers/isdn/hardware/avm/Config.in Wed Aug 14 10:53:57 2002 @@ -3,7 +3,7 @@ # mainmenu_option next_comment -comment 'Drivers for active AVM cards' +comment 'Active AVM cards' bool 'Support AVM cards' CONFIG_CAPI_AVM = drivers/isdn/hisax/Config.in 1.9 vs edited = --- 1.9/drivers/isdn/hisax/Config.inTue Jul 30 07:15:09 2002 +++ edited/drivers/isdn/hisax/Config.in Wed Aug 14 11:01:20 2002 @@ -1,5 +1,5 @@ mainmenu_option next_comment -comment 'Passive ISDN cards' +comment 'Passive cards' dep_tristate 'HiSax SiemensChipSet driver support' CONFIG_ISDN_DRV_HISAX $CONFIG_ISDN if [ $CONFIG_ISDN_DRV_HISAX != n ]; then comment ' D-channel protocol features' = drivers/isdn/i4l/Config.in 1.3 vs edited = --- 1.3/drivers/isdn/i4l/Config.in Sun Apr 21 23:07:44 2002 +++ edited/drivers/isdn/i4l/Config.in Wed Aug 14 10:47:42 2002 @@ -24,22 +24,5 @@ dep_tristate 'Support isdn diversion services' CONFIG_ISDN_DIVERSION $CONFIG_ISDN endmenu -comment 'low-level hardware drivers' - -source drivers/isdn/hisax/Config.in - -### Active ISDN cards - -mainmenu_option next_comment -comment 'Active ISDN cards' - -source drivers/isdn/icn/Config.in -source drivers/isdn/pcbit/Config.in -source drivers/isdn/sc/Config.in -source drivers/isdn/act2000/Config.in -source drivers/isdn/eicon/Config.in -source drivers/isdn/tpam/Config.in -source drivers/isdn/hysdn/Config.in - endmenu --- This sf.net email is sponsored by: Dice - The leading online job board for high-tech professionals. Search and apply for tech jobs today! http://seeker.dice.com/seeker.epl?rel_code=31 ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: [patch] kernel config 3/N - move sound into drivers/media
On Tue, 13 Aug 2002, Peter Samuelson wrote: Here's another one - this should fix the forward dependency between CONFIG_SOUND and CONFIG_SOUND_ACI_MIXER, by moving the sound config into the Multimedia menu - where I think it belongs anyway. Hmmh, makes sense to me, but there will probably be people complaining sound config has disappeared for me ;) The big loser here is ARM - it no longer suppresses the sound card question for the appropriate boards. But it's just one question, so I didn't sweat it too much. Well, I think that's okay, but you should check back with _rmk_. What I like about that patch is that it actually removes duplicated code. I think that's exactly where this effort should start. For example, the SCSI patch didn't do this, though AFAICS it would be nicely possible to unconditionally source drivers/scsi/Config.in and then have the if in there. These are trivial changes, and they make it easier to see what's happening in the patches which actually change behavior. Taking that a step further, this should also be a nice opportunity to introduce drivers/Config.in and remove even more duplication from arch/$ARCH/config.in. It comes of the cost of testing for the architecture, since e.g. s390 does not want to include most of drivers/*, but that means we'd actually collect this knowledge at a centralized place. Introducing drivers/Config.in could be done nicely piecemeal as well, without any change in behavior which is always good. It would also provide a possibility to not lose the ARM knowledge. I think it's basically just a question of taste if you prefer to initial global subsystem question in drivers/Config.in or drivers/subsys/Config.in. drivers/isdn/Config.in starts with mainmenu_option next_comment comment 'ISDN subsystem' if [ $CONFIG_NET != n ]; then bool 'ISDN support' CONFIG_ISDN_BOOL if [ $CONFIG_ISDN_BOOL = y ]; then mainmenu_option next_comment since I did not like having that duplicated in each arch/*/config.in. It also makes sense in the have as much information as possible about a subsystem located in one place (drivers/subsys). By the way, if you do these kind of changes, also check Config.help, you may be able to remove duplicated entries there as well ;) The drawbacks of that solution as opposed to having the above in drivers/Config.in and ending with source drivers/isdn/Config.in are: o We need to source all the Config.in files even when the subsys gets disabled, since we cannot know that beforehand o The trivial patches moving statements like the above into the subsys/Config.in means that all of that file should be indented, which makes the patches look really large, even though they change very little. I have no strong opinion either way, but I'd certainly like a drivers/Config.in. Oh, what I don't like about your patches: You don't include them inline, so I cannot easily (R)eply to them and have them quoted ;) --Kai --- This sf.net email is sponsored by: Dice - The leading online job board for high-tech professionals. Search and apply for tech jobs today! http://seeker.dice.com/seeker.epl?rel_code=31 ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: [patch] kernel config 3/N - move sound into drivers/media
[I wrote] Here's another one - this should fix the forward dependency between CONFIG_SOUND and CONFIG_SOUND_ACI_MIXER, by moving the sound config into the Multimedia menu - where I think it belongs anyway. [Kai Germaschewski] Hmmh, makes sense to me, but there will probably be people complaining sound config has disappeared for me ;) You are probably right. I still think it's the right thing to do. (: I do *not* like the recent proliferation of toplevel menu entries. Well, I think that's okay, but you should check back with _rmk_. True. The trouble with this sort of work is that you *have* to touch all the architectures, and sometimes change the behavior somewhat. That can mean stepping on toes now and then. What I like about that patch is that it actually removes duplicated code. I think that's exactly where this effort should start. For example, the SCSI patch didn't do this, though AFAICS it would be nicely possible to unconditionally source drivers/scsi/Config.in and then have the if in there. I thought about that - but didn't want to re-indent the whole file. I hate doing that. (: Also, there's a *reason* every arch has a separate config.in file - for maximum flexibility without putting lots of ifdefs in common code. To a certain extent I agree with you and I wish it were possible to eliminate the arch/*/config.in entirely, but it's not. ESR tried it with CML2 and was slapped down by Linus himself, as I recall. I don't want my humble efforts to end up the same way CML2 did. For that reason I'm trying very hard to make only small, incremental, obvious changes. Perhaps I'm a bit *too* timid. It comes of the cost of testing for the architecture, since e.g. s390 does not want to include most of drivers/*, but that means we'd actually collect this knowledge at a centralized place. What we need is an easy way to check for any arch. CONFIG_ARCH_S390 is the right idea (though s390x sets it as well, not sure if that's good or bad). Then again, such checks polluting the common code is exactly what the current system (with all its cut/paste code in arch/*/config.in) is supposed to prevent. Perhaps The Powers That Be like the status quo. Introducing drivers/Config.in could be done nicely piecemeal as well, without any change in behavior which is always good. It would also provide a possibility to not lose the ARM knowledge. H ... I didn't see any clean way to keep the arm test. Thinking about it some more, I suppose one could do if [ $CONFIG_ARM = y ]; then if [ ... ]; then tristate CONFIG_SOUND fi else tristate CONFIG_SOUND fi It's still not pretty, but should work. I think I'll put that in drivers/media/Config.in. By the way, if you do these kind of changes, also check Config.help, you may be able to remove duplicated entries there as well ;) I'd been avoiding Config.help - I was afraid if I looked in it I would find entries I would have to move from one dir to another. (: I have no strong opinion either way, but I'd certainly like a drivers/Config.in. Agreed. Oh, what I don't like about your patches: You don't include them inline, so I cannot easily (R)eply to them and have them quoted ;) Sorry about that - I agree. I only attached patches when I had more than one for a single mail, and then I forgot to switch back. Must recompile self with -finline-patches Peter --- This sf.net email is sponsored by: Dice - The leading online job board for high-tech professionals. Search and apply for tech jobs today! http://seeker.dice.com/seeker.epl?rel_code=31 ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
