Re: Cross-referencing frenzy
On Thu, 19 Apr 2001, Eric S. Raymond wrote: > Andreas Dilger <[EMAIL PROTECTED]>: > > However, I'm not sure that your reasoning for removing these is correct. > > For example, one symbol that I saw was CONFIG_EXT2_CHECK, which is code > > that used to be enabled in the kernel, but is currently #ifdef'd out with > > the above symbol. When Ted changed this, he wasn't sure whether we would > > need the code again in the future. I enable it sometimes when I'm doing > > ext2 development, but it may not be worthy of a separate config option > > that 99.9% of people will just be confused about. > > I think things like that don't belong in the CONFIG_ namespace to begin > with. How about CONFIG_DEBUG_ or just simply DEBUG_? You could even have a CML add-on or switch that configures the various DEBUG_ options (but perhaps thats a bit too strange). - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [kbuild-devel] Re: Cross-referencing frenzy
[esr] > > CONFIG_SOUND_YMPCI: arch/ppc/configs/power3_defconfig >arch/arm/def-configs/footbridge arch/arm/def-configs/rpc arch/arm/def-configs/lart >arch/arm/def-configs/shark [jgarzik] > typo, that should be ...YMFPCI. Actually it's not a typo (although the fix is the same). The old "SB-compatible mode" Yamaha driver was indeed CONFIG_SOUND_YMPCI. That allowed the two to coexist while the native-mode driver matured. Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Cross-referencing frenzy
Andreas Dilger <[EMAIL PROTECTED]>: > Could you make a list that splits the symbols up by each of the above > failure conditions? It would make the task of deciding how to fix the > "problem" more apparent. There are 32 possible categories. I need to eyeball them and decide which ones are significant. > Also, it appears that some of the symbols you are matching are only in > documentation (which isn't necessarily a bad thing). I would start with: > > *.[chS] Config.in Makefile Configure.help There should be few enough of these to fit on one screen. Over 700 dead symbols indicates a larger problem. > However, I'm not sure that your reasoning for removing these is correct. > For example, one symbol that I saw was CONFIG_EXT2_CHECK, which is code > that used to be enabled in the kernel, but is currently #ifdef'd out with > the above symbol. When Ted changed this, he wasn't sure whether we would > need the code again in the future. I enable it sometimes when I'm doing > ext2 development, but it may not be worthy of a separate config option > that 99.9% of people will just be confused about. I think things like that don't belong in the CONFIG_ namespace to begin with. -- http://www.tuxedo.org/~esr/">Eric S. Raymond "To disarm the people... was the best and most effectual way to enslave them." -- George Mason, speech of June 14, 1788 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [kbuild-devel] Re: Cross-referencing frenzy
Eric S. Raymond wrote: > Rogier Wolff <[EMAIL PROTECTED]>: > > I think it should be possible to do: > > > > /* to enable the special stuff, change the "undef" to "define", > >If you really want you can add this to Config.in so that you're presented > >with this choice when configuring your kernel. But it's not neccesary > >for the general public to always see this toggle. */ > > #undef CONFIG_SX_SPECIALSTUFF > > > > #ifdef CONFIG_SX_SPECIALSTUFF > > ... > > > > #endif > > Yes, I could write and test code to handle this in about twenty minutes. > And I was about to do it when I realized that it would be the wrong thing. > > The right answer is that CONFIG_SX_SPECIALSTUFF *should* be flagged as > an error -- because it doesn't belong in the CONFIG_ namespace, which > by definition should be reserved for things the configurators control. > > It should be called something else: perhaps ENABLE_SX_SPECIALSTUFF You surely can do #undef ENABLE_SX_SPECIALSTUFF however, then the "upgrade path" to a configurable parameter in the configuration stuff is harder. Now, as far as I know, this is rarely (if ever) used right now. (but I've been tempted to do it in the past) Maybe with better configuration tools, always declaring it a configuration option is a good idea. Think about it. Consider the issue, decide whatever you want. Tell me about it. (i.e. what you suggest is the best way to deal with this.) (*) Roger. (*) you may say: "But I just did that". However the above hints at that you skipped over the "but I'd like to prepare for the case where the configuration of that parameter should be made easier by including it in the config mechanism." -- ** [EMAIL PROTECTED] ** http://www.BitWizard.nl/ ** +31-15-2137555 ** *-- BitWizard writes Linux device drivers for any device you may have! --* * There are old pilots, and there are bold pilots. * There are also old, bald pilots. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Cross-referencing frenzy
Jeff Garzik <[EMAIL PROTECTED]>: > "Eric S. Raymond" wrote: > > CONFIG_SOUND_YMPCI: arch/ppc/configs/power3_defconfig >arch/arm/def-configs/footbridge arch/arm/def-configs/rpc arch/arm/def-configs/lart >arch/arm/def-configs/shark > > typo, that should be ...YMFPCI. > > maybe you could add soundex to catch misspellings ;-) Don't laugh. I considered it -- only not with soundex but with Ratcliff/Obershelp gestalt similarity matching, which is better at catching this sort of typo. Python has a module for this; I could make it happen with about two hours' work. -- http://www.tuxedo.org/~esr/">Eric S. Raymond You need only reflect that one of the best ways to get yourself a reputation as a dangerous citizen these days is to go about repeating the very phrases which our founding fathers used in the great struggle for independence. -- Attributed to Charles Austin Beard (1874-1948) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Cross-referencing frenzy
"Eric S. Raymond" wrote: > CONFIG_SOUND_YMPCI: arch/ppc/configs/power3_defconfig >arch/arm/def-configs/footbridge arch/arm/def-configs/rpc arch/arm/def-configs/lart >arch/arm/def-configs/shark typo, that should be ...YMFPCI. maybe you could add soundex to catch misspellings ;-) -- Jeff Garzik | "The universe is like a safe to which there is a Building 1024 | combination -- but the combination is locked up MandrakeSoft | in the safe."-- Peter DeVries - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Cross-referencing frenzy
Russell King <[EMAIL PROTECTED]>: > On Wed, Apr 18, 2001 at 11:34:45PM -0400, Eric S. Raymond wrote: > > Especially look for CONFIG_* symbols that only occur in .c or .h files. > > I think almost every one of those lines represents a bug that needs to be > > fixed. > > It'd be easier to read if they were alphanumerically sorted. Good thought. Done. This feature will be in the 1.2.1 version. > The ones that show up in arch/arm/def-configs are purely because I've been > keeping back the updates to these files; each time the config structure > changes, I get a nice big patch from people with the new def-configs. I > didn't want to inflict this too regularly on people. Funny you should mention that. The first correction patch I was planning to generate was one to remove orphans in *all* the defconfigs. I figured this would be about the least controversial way to start the cleanup, and it will deal with 82 of the 699 identified broken symbols. For this case, I can generate a correct patch mechanically. Here is the relevant report, generated with kxref.py -f "d&~(c|h|o|m)": CONFIG_ADDIN_FOOTBRIDGE: arch/arm/defconfig CONFIG_AEC6210_TUNING: arch/ia64/defconfig CONFIG_AMD_FLASH: arch/ppc/configs/SM850_defconfig arch/ppc/configs/TQM823L_defconfig arch/ppc/configs/TQM850L_defconfig arch/ppc/configs/TQM860L_defconfig CONFIG_ASH: arch/arm/def-configs/clps7500 arch/arm/def-configs/shark CONFIG_AUTODETECT_RAID: arch/ppc/configs/power3_defconfig CONFIG_BLK_DEV_AEC6210: arch/ia64/defconfig CONFIG_BLK_DEV_FLD7500: arch/arm/def-configs/clps7500 CONFIG_CERF_CS8900A: arch/arm/def-configs/cerf CONFIG_CLPS7500_FLASH: arch/arm/def-configs/clps7500 CONFIG_CMD64X_RAID: arch/arm/defconfig arch/ia64/defconfig CONFIG_CPU_ARM2: arch/arm/def-configs/empeg arch/arm/def-configs/victor arch/arm/def-configs/sherman CONFIG_CPU_ARM3: arch/arm/def-configs/empeg arch/arm/def-configs/victor arch/arm/def-configs/sherman CONFIG_CPU_ARM6: arch/arm/def-configs/rpc arch/arm/def-configs/empeg arch/arm/def-configs/victor arch/arm/def-configs/sherman CONFIG_CPU_ARM7: arch/arm/def-configs/rpc arch/arm/def-configs/empeg arch/arm/def-configs/victor arch/arm/def-configs/clps7500 arch/arm/def-configs/sherman CONFIG_CPU_ARM920: arch/arm/def-configs/integrator CONFIG_CPU_IS_SLOW: arch/arm/def-configs/empeg CONFIG_DEBUG_USER_BACKTRACE: arch/arm/def-configs/empeg CONFIG_EMPEG_HENRY: arch/arm/def-configs/empeg CONFIG_EMPEG_IR: arch/arm/def-configs/empeg CONFIG_EMPEG_USB: arch/arm/def-configs/empeg CONFIG_FB_CLPS711X: arch/arm/def-configs/footbridge arch/arm/def-configs/rpc CONFIG_FB_MQ200: arch/arm/def-configs/assabet arch/arm/def-configs/neponset CONFIG_FIREWALL: arch/arm/def-configs/empeg CONFIG_FLASH: arch/ppc/configs/IVMS8_defconfig arch/ppc/configs/SM850_defconfig arch/ppc/configs/SPD823TS_defconfig arch/ppc/configs/TQM823L_defconfig arch/ppc/configs/TQM850L_defconfig arch/ppc/configs/TQM860L_defconfig CONFIG_FRAME_POINTER: arch/arm/defconfig arch/arm/def-configs/a5k arch/arm/def-configs/ebsa110 arch/arm/def-configs/footbridge arch/arm/def-configs/rpc arch/arm/def-configs/brutus arch/arm/def-configs/empeg arch/arm/def-configs/victor arch/arm/def-configs/assabet arch/arm/def-configs/graphicsclient arch/arm/def-configs/lart arch/arm/def-configs/lusl7200 arch/arm/def-configs/cerf arch/arm/def-configs/clps7500 arch/arm/def-configs/shark arch/arm/def-configs/integrator arch/arm/def-configs/neponset arch/arm/def-configs/pangolin arch/arm/def-configs/sherman CONFIG_GDB_STUB_VBR: arch/sh/defconfig CONFIG_GEMINI: arch/ppc/configs/ibmchrp_defconfig CONFIG_GENRTC: arch/parisc/defconfig CONFIG_HIL: arch/parisc/defconfig CONFIG_HPT366_FIP: arch/arm/defconfig arch/ia64/defconfig CONFIG_HPT366_MODE3: arch/arm/defconfig arch/ia64/defconfig CONFIG_IDEDMA_PCI_EXPERIMENTAL: arch/arm/defconfig arch/ia64/defconfig CONFIG_INET_RARP: arch/arm/def-configs/empeg CONFIG_INPUT_MOUSEDEV_DIGITIZER: arch/arm/defconfig CONFIG_INPUT_MOUSEDEV_MIX: arch/arm/defconfig CONFIG_IP_ALIAS: arch/ppc/configs/IVMS8_defconfig arch/ppc/configs/SM850_defconfig arch/ppc/configs/SPD823TS_defconfig arch/ppc/configs/TQM823L_defconfig arch/ppc/configs/TQM850L_defconfig arch/ppc/configs/TQM860L_defconfig arch/m68k/defconfig arch/arm/defconfig arch/arm/def-configs/empeg arch/arm/def-configs/lart arch/arm/def-configs/cerf arch/arm/def-configs/clps7500 arch/arm/def-configs/shark CONFIG_IP_ROUTER: arch/ppc/configs/IVMS8_defconfig arch/ppc/configs/SM850_defconfig arch/ppc/configs/SPD823TS_defconfig arch/ppc/configs/TQM823L_defconfig arch/ppc/configs/TQM850L_defconfig arch/ppc/configs/TQM860L_defconfig arch/m68k/defconfig arch/arm/defconfig arch/arm/def-configs/empeg arch/arm/def-configs/lart arch/arm/def-configs/cerf arch/arm/def-configs/clps7500 arch/arm/def-configs/shark CONFIG_IT8172_TUNING: arch/mips/defconfig-it8172 CONFIG_IT8712: arch/mips/defconfig-it8172 CONFIG_JULIETTE_CCD: arch/cris/defconfig CONFIG_JULIETTE_MEGCCD: arch/cris/defconfig CONFIG_JULIETTE_SS1M: arch/cri
Re: [kbuild-devel] Re: Cross-referencing frenzy
Rogier Wolff <[EMAIL PROTECTED]>: > I think it should be possible to do: > > /* to enable the special stuff, change the "undef" to "define", >If you really want you can add this to Config.in so that you're presented >with this choice when configuring your kernel. But it's not neccesary >for the general public to always see this toggle. */ > #undef CONFIG_SX_SPECIALSTUFF > > #ifdef CONFIG_SX_SPECIALSTUFF > ... > > #endif Yes, I could write and test code to handle this in about twenty minutes. And I was about to do it when I realized that it would be the wrong thing. The right answer is that CONFIG_SX_SPECIALSTUFF *should* be flagged as an error -- because it doesn't belong in the CONFIG_ namespace, which by definition should be reserved for things the configurators control. It should be called something else: perhaps ENABLE_SX_SPECIALSTUFF -- http://www.tuxedo.org/~esr/">Eric S. Raymond The IRS has become morally corrupted by the enormous power which we in Congress have unwisely entrusted to it. Too often it acts like a Gestapo preying upon defenseless citizens. -- Senator Edward V. Long - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Cross-referencing frenzy
On Wed, Apr 18, 2001 at 10:49:01PM -0600, Andreas Dilger wrote: > However, I'm not sure that your reasoning for removing these is correct. > For example, one symbol that I saw was CONFIG_EXT2_CHECK, which is code > that used to be enabled in the kernel, but is currently #ifdef'd out with > the above symbol. When Ted changed this, he wasn't sure whether we would How about something besides CONFIG_ then? Like maybe DEV_CONFIG_ or DEV_. The CONFIG_ name space should be reserved for things that can be configured via the config mechanism. Things that only developers or special testers might want should use something other than the CONFIG_ namespace. mrc -- Mike Castle Life is like a clock: You can work constantly [EMAIL PROTECTED] and be right all the time, or not work at all www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc We are all of us living in the shadow of Manhattan. -- Watchmen - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Cross-referencing frenzy
> > > CONFIG_DEVFS: Documentation/filesystems/devfs/ChangeLog > > > > These are options that used to be used, > > > These should not be removed > > This makes no sense at all. Do you have any particular > reason for keeping this deadwood around ? Because its a changelog ? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Cross-referencing frenzy
Eric S. Raymond wrote: > Richard Gooch <[EMAIL PROTECTED]>: > > > Look at the filename. ;-) They're not being kept around, they just > > > happen to be mentioned in the devfs ChangeLog, and esr's overzealous > > > crossref tool caught them. *grin* > > I've already fixed that. > > > A cleaner solution is to parse the source code, ignoring comment > > blocks. However, that's a bit more work. > > Not too hard. I think I can do that. Eric, I think it should be possible to do: /* to enable the special stuff, change the "undef" to "define", If you really want you can add this to Config.in so that you're presented with this choice when configuring your kernel. But it's not neccesary for the general public to always see this toggle. */ #undef CONFIG_SX_SPECIALSTUFF #ifdef CONFIG_SX_SPECIALSTUFF ... #endif Roger. -- ** [EMAIL PROTECTED] ** http://www.BitWizard.nl/ ** +31-15-2137555 ** *-- BitWizard writes Linux device drivers for any device you may have! --* * There are old pilots, and there are bold pilots. * There are also old, bald pilots. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Cross-referencing frenzy
On Wed, Apr 18, 2001 at 11:34:45PM -0400, Eric S. Raymond wrote: > Especially look for CONFIG_* symbols that only occur in .c or .h files. > I think almost every one of those lines represents a bug that needs to be > fixed. It'd be easier to read if they were alphanumerically sorted. The ones that show up in arch/arm/def-configs are purely because I've been keeping back the updates to these files; each time the config structure changes, I get a nice big patch from people with the new def-configs. I didn't want to inflict this too regularly on people. -- Russell King ([EMAIL PROTECTED])The developer of ARM Linux http://www.arm.linux.org.uk/personal/aboutme.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Cross-referencing frenzy
Richard Gooch wrote: > Exactly. A ChangeLog should pre preserved for all time. It is an > incredibly useful tool. Many times I've gone back and checked when > something was done, and in relation to other changes before, after or > around the same time. agreed > Except the CONFIG_APM_IGNORE_SUSPEND_BOUNCE was in the apm.c source > file (in a ChangeLog). So just ignoring Documentation/ won't solve the > problem. > > One trick I've used on my own (non-Linux) code is to insert a space > after the first underscore. That fools the global search, but leaves > the essence of the ChangeLog entry. It's a bit hackish, though. > > A cleaner solution is to parse the source code, ignoring comment > blocks. However, that's a bit more work. Or CC the maintainers, who can manually check, distributing the work :) The stuff in ChangeLogs is clearly not to be touched. Various documentation has to be examined manually to determine if its outdated or not. There is no 100% automatic way to do this. Jeff -- Jeff Garzik | "The universe is like a safe to which there is a Building 1024 | combination -- but the combination is locked up MandrakeSoft | in the safe."-- Peter DeVries - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Cross-referencing frenzy
Richard Gooch <[EMAIL PROTECTED]>: > > Look at the filename. ;-) They're not being kept around, they just > > happen to be mentioned in the devfs ChangeLog, and esr's overzealous > > crossref tool caught them. *grin* I've already fixed that. > A cleaner solution is to parse the source code, ignoring comment > blocks. However, that's a bit more work. Not too hard. I think I can do that. -- http://www.tuxedo.org/~esr/">Eric S. Raymond Non-cooperation with evil is as much a duty as cooperation with good. -- Mohandas Gandhi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Cross-referencing frenzy
Edward S. Marshall <[EMAIL PROTECTED]>: > Look at the filename. ;-) They're not being kept around, they just happen > to be mentioned in the devfs ChangeLog, and esr's overzealous crossref > tool caught them. *grin* > > Perhaps the tool should be modified to exempt comments in code and files > in Documentation/*? :-) No. But it should ignore change logs. I'll fix it to do that. -- http://www.tuxedo.org/~esr/">Eric S. Raymond The Bible is not my book, and Christianity is not my religion. I could never give assent to the long, complicated statements of Christian dogma. -- Abraham Lincoln - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Cross-referencing frenzy
Edward S. Marshall writes: > On Thu, Apr 19, 2001 at 01:11:07AM -0300, Rik van Riel wrote: > > On Thu, 19 Apr 2001, Richard Gooch wrote: > > > esr wrote: > > > > CONFIG_DEVFS: Documentation/filesystems/devfs/ChangeLog > > > > > > These are options that used to be used, > > > > > These should not be removed > > > > This makes no sense at all. Do you have any particular > > reason for keeping this deadwood around ? > > Look at the filename. ;-) They're not being kept around, they just > happen to be mentioned in the devfs ChangeLog, and esr's overzealous > crossref tool caught them. *grin* Exactly. A ChangeLog should pre preserved for all time. It is an incredibly useful tool. Many times I've gone back and checked when something was done, and in relation to other changes before, after or around the same time. > Perhaps the tool should be modified to exempt comments in code and > files in Documentation/*? :-) Except the CONFIG_APM_IGNORE_SUSPEND_BOUNCE was in the apm.c source file (in a ChangeLog). So just ignoring Documentation/ won't solve the problem. One trick I've used on my own (non-Linux) code is to insert a space after the first underscore. That fools the global search, but leaves the essence of the ChangeLog entry. It's a bit hackish, though. A cleaner solution is to parse the source code, ignoring comment blocks. However, that's a bit more work. Either way, the solution adopted has to kill off the false positives. It's not good enough to build up a list of CONFIG options to ignore, as it will get stale. Furthermore, that list might be overlooked by someone on a cleanup crusade, with the result that a patch gets sent to Linus which "fixes" the "broken" CONFIG symbols. And since too many global patches are not Cc'ed to the maintainers, this kind of crap slips by. Frankly, I'd rather see stale symbols left around, and have it really difficult to detect them. Eric is making a tool that makes it too easy for a random person to "detect" "problems" and then "fix" them, thinking that "progess" is being made. In reality, it's just regress. Regards, Richard Permanent: [EMAIL PROTECTED] Current: [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Cross-referencing frenzy
Eric writes: > So. I've written a cross-reference analyzer for the configuration symbol > namespace. It's included with CML 1.2.0, which I just released. The > main reason I wrote it was to detect broken symbols. > > A symbol is non-broken when: > * It is used in either code or a Makefile > * It is set in a (CML1) configuration file > * It is either derived from other non-broken symbols > or described in Configure.help > If it fails any one of these conditions, it's cruft that makes the kernel > code harder to maintain and understand. The least bad way to be broken is > to be useful but not documented. The most bad way is to lurk in code, doing > nothing but making the code harder to understand and maintain. Could you make a list that splits the symbols up by each of the above failure conditions? It would make the task of deciding how to fix the "problem" more apparent. Also, it appears that some of the symbols you are matching are only in documentation (which isn't necessarily a bad thing). I would start with: *.[chS] Config.in Makefile Configure.help However, I'm not sure that your reasoning for removing these is correct. For example, one symbol that I saw was CONFIG_EXT2_CHECK, which is code that used to be enabled in the kernel, but is currently #ifdef'd out with the above symbol. When Ted changed this, he wasn't sure whether we would need the code again in the future. I enable it sometimes when I'm doing ext2 development, but it may not be worthy of a separate config option that 99.9% of people will just be confused about. Cheers, Andreas -- Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto, \ would they cancel out, leaving him still hungry?" http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Cross-referencing frenzy
On Thu, Apr 19, 2001 at 01:11:07AM -0300, Rik van Riel wrote: > On Thu, 19 Apr 2001, Richard Gooch wrote: > > esr wrote: > > > CONFIG_DEVFS: Documentation/filesystems/devfs/ChangeLog > > > > These are options that used to be used, > > > These should not be removed > > This makes no sense at all. Do you have any particular > reason for keeping this deadwood around ? Look at the filename. ;-) They're not being kept around, they just happen to be mentioned in the devfs ChangeLog, and esr's overzealous crossref tool caught them. *grin* Perhaps the tool should be modified to exempt comments in code and files in Documentation/*? :-) -- Edward S. Marshall <[EMAIL PROTECTED]>http://www.nyx.net/~emarshal/ --- [ Felix qui potuit rerum cognoscere causas. ] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Cross-referencing frenzy
On Thu, 19 Apr 2001, Richard Gooch wrote: > > CONFIG_APM_IGNORE_SUSPEND_BOUNCE: arch/i386/kernel/apm.c > > CONFIG_DEVFS_TTY_COMPAT: Documentation/filesystems/devfs/ChangeLog > > CONFIG_DEVFS_BOOT_OPTIONS: Documentation/filesystems/devfs/ChangeLog > > CONFIG_DEVFS_DISABLE_OLD_NAMES: Documentation/filesystems/devfs/ChangeLog > > CONFIG_DEVFS_DISABLE_OLD_TTY_NAMES: Documentation/filesystems/devfs/ChangeLog > > CONFIG_DEVFS_ONLY: Documentation/filesystems/devfs/ChangeLog > > CONFIG_DEVFS: Documentation/filesystems/devfs/ChangeLog > > These are options that used to be used, > These should not be removed This makes no sense at all. Do you have any particular reason for keeping this deadwood around ? Rik -- Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com.br/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Cross-referencing frenzy
Eric S. Raymond writes: > So. I've written a cross-reference analyzer for the configuration symbol > namespace. It's included with CML 1.2.0, which I just released. The > main reason I wrote it was to detect broken symbols. > > A symbol is non-broken when: > * It is used in either code or a Makefile > * It is set in a (CML1) configuration file > * It is either derived from other non-broken symbols > or described in Configure.help Ouch! You've got a number of false positives here. Some that struck me: > CONFIG_APM_IGNORE_SUSPEND_BOUNCE: arch/i386/kernel/apm.c > CONFIG_DEVFS_TTY_COMPAT: Documentation/filesystems/devfs/ChangeLog > CONFIG_DEVFS_BOOT_OPTIONS: Documentation/filesystems/devfs/ChangeLog > CONFIG_DEVFS_DISABLE_OLD_NAMES: Documentation/filesystems/devfs/ChangeLog > CONFIG_DEVFS_DISABLE_OLD_TTY_NAMES: Documentation/filesystems/devfs/ChangeLog > CONFIG_DEVFS_ONLY: Documentation/filesystems/devfs/ChangeLog > CONFIG_DEVFS: Documentation/filesystems/devfs/ChangeLog These are options that used to be used, and now only reside in documentation, ChangeLogs or in comments. These should not be removed from the tree, irrespective of whether they cause your broken symbol code to detect them. Regards, Richard Permanent: [EMAIL PROTECTED] Current: [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Cross-referencing frenzy
So. I've written a cross-reference analyzer for the configuration symbol namespace. It's included with CML 1.2.0, which I just released. The main reason I wrote it was to detect broken symbols. A symbol is non-broken when: * It is used in either code or a Makefile * It is set in a (CML1) configuration file * It is either derived from other non-broken symbols or described in Configure.help If it fails any one of these conditions, it's cruft that makes the kernel code harder to maintain and understand. The least bad way to be broken is to be useful but not documented. The most bad way is to lurk in code, doing nothing but making the code harder to understand and maintain. There are 731 apparently broken symbols out of 2096 total in the 2.4.4pre4 -- more than one-third of the entire namespace! Here's a cross-reference report. Read it and weep...even given that a couple dozen of these are things like CONFIG_PARTITION_ADVANCED that are CML1 derived symbols, there are a lot of "most bad" broken symbols out there. Especially look for CONFIG_* symbols that only occur in .c or .h files. I think almost every one of those lines represents a bug that needs to be fixed. CONFIG_KHTTPD_NUMCPU: net/khttpd/datasending.c net/khttpd/main.c net/khttpd/prototypes.h net/khttpd/waitheaders.c CONFIG_SGI_IO: include/asm-mips64/sn/addrs.h include/asm-mips64/sn/arch.h include/asm-mips64/sn/io.h include/asm-mips64/sn/klconfig.h include/asm-mips64/sn/kldir.h CONFIG_GENRTC: arch/parisc/defconfig CONFIG_ARCH_EBSA285_HOST: arch/arm/config.in arch/arm/def-configs/footbridge Documentation/Configure.help CONFIG_COBALT_LCD: arch/mips/config.in arch/mips/defconfig-cobalt CONFIG_LOCKED: drivers/pcmcia/cs.c drivers/pcmcia/cs_internal.h CONFIG_NLS_ABC: fs/nls/Makefile CONFIG_SMB_NLS_DEFAULT: fs/Config.in arch/sparc/defconfig arch/mips/defconfig-cobalt Documentation/Configure.help CONFIG_PP04: arch/ppc/8xx_io/uart.c CONFIG_FREQ_RTC: include/asm-ia64/sn/sn1/ip27config.h CONFIG_PARTITION_ADVANCED: fs/partitions/Config.in arch/i386/defconfig arch/alpha/defconfig arch/sparc/defconfig arch/mips/defconfig arch/mips/defconfig-decstation arch/mips/defconfig-ip22 arch/mips/defconfig-cobalt arch/mips/defconfig-rm200 arch/mips/defconfig-orion arch/mips/defconfig-ddb5476 arch/mips/defconfig-it8172 arch/ppc/defconfig arch/ppc/configs/apus_defconfig arch/ppc/configs/common_defconfig arch/ppc/configs/bseip_defconfig arch/ppc/configs/mbx_defconfig arch/ppc/configs/oak_defconfig arch/ppc/configs/power3_defconfig arch/ppc/configs/est8260_defconfig arch/ppc/configs/walnut_defconfig arch/ppc/configs/rpxcllf_defconfig arch/ppc/configs/rpxlite_defconfig arch/ppc/configs/ibmchrp_defconfig arch/ppc/configs/IVMS8_defconfig arch/ppc/configs/SM850_defconfig arch/ppc/configs/SPD823TS_defconfig arch/ppc/configs/TQM823L_defconfig arch/ppc/configs/TQM850L_defconfig arch/ppc/configs/TQM860L_defconfig arch/m68k/defconfig arch/sparc64/defconfig arch/arm/defconfig arch/arm/def-configs/a5k arch/arm/def-configs/ebsa110 arch/arm/def-configs/footbridge arch/arm/def-configs/rpc arch/arm/def-configs/brutus arch/arm/def-configs/assabet arch/arm/def-configs/graphicsclient arch/arm/def-configs/lart arch/arm/def-configs/lusl7200 arch/arm/def-configs/cerf arch/arm/def-configs/clps7500 arch/arm/def-configs/shark arch/arm/def-configs/integrator arch/arm/def-configs/neponset arch/arm/def-configs/pangolin arch/sh/defconfig arch/ia64/defconfig arch/mips64/defconfig arch/mips64/defconfig-ip22 arch/mips64/defconfig-ip27 arch/s390/defconfig arch/parisc/defconfig arch/cris/defconfig arch/s390x/defconfig Documentation/Configure.help CONFIG_LOWLEVEL_SOUND: Documentation/sound/Wavefront CONFIG_MDISK: init/main.c drivers/block/ll_rw_blk.c CONFIG_PACKET_MULTICAST: net/packet/af_packet.c CONFIG_WARNING: drivers/net/tokenring/smctr.h CONFIG_BLK_DEV_FLASH: arch/arm/def-configs/brutus arch/arm/def-configs/assabet arch/arm/def-configs/graphicsclient arch/arm/def-configs/lart arch/arm/def-configs/cerf arch/arm/def-configs/neponset arch/arm/def-configs/pangolin arch/arm/def-configs/sherman arch/cris/kernel/setup.c CONFIG_DE_AOC: drivers/isdn/Config.in arch/mips/defconfig-cobalt Documentation/Configure.help CONFIG_SCSI_DECSII: drivers/scsi/Config.in arch/mips/defconfig-decstation CONFIG_VIDEO_VESA: arch/i386/boot/video.S Documentation/svga.txt CONFIG_FB_PCI: drivers/video/Config.in arch/sparc64/defconfig CONFIG_IPV6_SUBTREES: net/ipv6/ip6_fib.c net/ipv6/route.c CONFIG_CPU_ARM10_I_CACHE_ON: arch/arm/config.in CONFIG_B1DMA_POLLDEBUG: drivers/isdn/avmb1/b1dma.c CONFIG_BOGUS: Documentation/kbuild/config-language.txt CONFIG_ELF_KERNEL: arch/mips/config.in arch/mips/defconfig arch/mips/defconfig-decstation arch/mips/defconfig-ip22 arch/mips/defconfig-cobalt arch/mips/defconfig-rm200 arch/mips/defconfig-orion arch/mips/defconfig-ddb5476 arch/mips/defconfig-it8172 CONFIG_VIDEO_LML33: drivers/media/video/Makefile drivers/media/video/i2c-old.
