[kbuild-devel] Problem with configurators and customized help texts perarchitecture.
Greetings all, Since kernel 2.5.3, the monolithic Configure.help file has been broken up into a hundred or so Config.help files. This division potentially allows for customized help texts for different architectures. For example, the CONFIG_SMP help text is different in arch/i386/Config.help and arch/ppc/Config.help. However, a limitation of the current configurators can make this a moot point. Robert Love recently posted a Configurable NR_CPUS for 2.5.24 patch which adds a help text for CONFIG_NR_CPUS. The help text for his patch is for the i386 arch only. Other architectures could display a help text thusly: For 32-bit architectures: CONFIG_NR_CPUS This allows you to specify the maximum number of CPUs which this kernel will support. The maximum supported value is 32 and the minimum value which makes sense is 2. This is purely to save memory - each supported CPU adds approximately eight kilobytes to the kernel image. For 64-bit architectures: CONFIG_NR_CPUS This allows you to specify the maximum number of CPUs which this kernel will support. The maximum supported value is 64 and the minimum value which makes sense is 2. This is purely to save memory - each supported CPU adds approximately eight kilobytes to the kernel image. I put together a trivial patch which adds the appropriate help text to the 12 other architectures effected by Robert's patch. The problem is that the current configurators generate a list of Config.help files which can have other architectures listed first. Here is a snippet from scripts/header.tk: # Now pick out right help text: set message [exec find . -name Config.help | xargs sed -n I don't know what determines the order in which find finds files, but on my machine I get this subset of files: ./drivers/telephony/Config.help ./arch/sparc64/Config.help ./arch/i386/Config.help ./arch/ppc/8260_io/Config.help The arch/sparc64/Config.help file is found before the arch/i386/Config.help file, so if a CONFIG_NR_CPUS help text is in sparc64, that is what I get when configuring for i386. Now, I realize that this particular problem could be easily solved by simply rewording the help text for CONFIG_NR_CPUS so that one text would be appropriate and accurate for all archs. For those of you wondering why we even have multiple copies of help texts scattered around different arch/xxx/Config.help files, one answer is that some distributions cut out the non-relevant arch source code from their shipped source trees. If customized help texts have any value, the configurators will have to be upgraded so that either non-relevant arches are ignored, or the relevant arch is searched first. Any volunteers? Comments? Steven --- This sf.net email is sponsored by: Jabber Inc. Don't miss the IM event of the season | Special offer for OSDN members! JabConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Your opinion on CML2 and kbuild-2.5
On Friday 15 February 2002 09:04, Tom Rini wrote: On Fri, Feb 15, 2002 at 11:22:00AM +0100, Giacomo Catenazzi wrote: [much sippage] The big problem in CML2 is python (and python2). This is a red herring. People bitch and moan about it, but it's not a problem. Agreed, but it is a minor irritation for me, and could be a major irritation for others. On my RH 7.2 system, the lpd startup scripts don't work with anything but Python 1.5.2, so I have to switch things around a little if I want to get lpd working. This is very easy to do, and I don't have this problem on Mandrake which is fully compatible with Python 2. The real problem with CML2 is 'enhancements' that come with the package. The first round of CML2 that goes into the kernel needs to match the current set, bug/feature for bug/feature, and counter intuitive to normal user question for coutner intuituve to normal user question. This is an extremely important point. When applications such as make xconfig and make menuconfig have been around a long time, a set of users will exist who will STRONGLY resist any change to the look and feel and operation of the interfaces to those programs. My own experience underscores this. I ported an old graphics applications program written for a VAX and a techtronics monochrome display to a Unix/X-window system. The port made use of color, and other features of X. But, oddly enough, very oddly enough, the users _demanded_ that the ported application have a Classic mode which had exactly the same look and feel as the old system which they had used for years. So, I went back and coded some more and everyone was happy. The new users used the new interface, while the fuddy-duddies continued to use the old Classic mode for a few years. So, having a make xconfig which has a classic mode which emulates as closely as possible the look and feel of the current system could be a good selling point. Steven ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] xconfig patch
On Saturday 02 February 2002 20:17, Michael Elizabeth Chastain wrote: Eric Raymond commented about the patch I submitted to xconfig, so I'd like to explain myself. I didn't fix xconfig; Olaf Dietsche did. I tested the patch and sent it to Linus in accordance with my duties as maintainer. After a week or two, I'll send it again, mark it try #2, and send copies to kbuild-devel (again) and lkml. And then try #3, and so on. One of these things is going to happen: . Linus will accept my CML1 patches. . Linus will reject my CML1 patches with a reason. . Linus will tell me that he doesn't want to see CML1 patches from me, which immediately raises the question of who *can* submit CML1 patches to him and get them considered. . Linus will keep blackholing patches from me. Then everybody in lkml is going to see Linus blackholing patches from an official maintainer. . Linus will do to CML1 what he did with Configure.help, and then he won't have to deal with the CML1 maintainer any more. That would mean he would need some kind of CML system from somewhere. . Something else that I haven't even thought of. ??? Linus may accept that patch from Dave Jones. 2.5.3-dj1 has Olaf's patch. Evidently DaveJ watches lkml pretty closely. He picked up one of my 6-line fixes to netfilter, and I didn't even cc to him. I am aware that I am oscillating between find a market alternative to Linus and work with Linus. In order to get to the point of looking for an alternative to Linus, I have to make one more sincere attempt to work with Linus. I discovered early on that: a) Linus ignores patches big and small, especially big. b) Alan applied patches which were correct and necessary. I hope that Dave Jones can fill Alan's shoes as the market alternative. Steven ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] cml2-1.9.10 problems with kxref.py script
On Wednesday 19 December 2001 09:47 pm, Eric S. Raymond wrote: Steven Cole [EMAIL PROTECTED]: I'm having problems getting the kxref.py script to run using recent versions of cml2. Hm. Looks likew Python versions before 2.2b1 get a little confused about nested scopes. I'll put out a 1.9.11 to address this. Hmmm. This is interesting. I got cml2-1.9.11, made a clean 2.4.17-rc2 tree, installed 1.9.11 and initially got the following errors. So, I grabbed Python 2.2c1 and of course it works just fine. Then, I re-ran kxref.py using the older snake (2.1) and it did _not_ blow up as below. I then deleted the kxref.out file and Python 2.1 created the wreckage seen below. I'll stick with Python 2.2c1 for now, so this is a non-issue for me, although it may be an issue for others who are relying on the RPMS which come with their distro of choice. Athough getting the latest Python is trivially easy, making it play nicely with the rest of the system can be more trouble. If anyone has patches for making the lpd-related scripts on RH 7.2 work with Python 2.[0,1,2], I'd certainly appreciate getting them. When CML2 goes into 2.5.x sometime soon, we probably need to specify the needed Python version in Documentation/Changes, along with the URLs of where to obtain it. Thanks for looking into this, Steven Results of cml2-1.9.11 and Python 2.1 after kxref.out is deleted: [root@spc linux-2.4.17-rc2-cml2]# scripts/kxref.py -e scripts/kxref.py:145: SyntaxWarning: local name 'definere' in 'makexref' shadows use of 'definere' as global in nested scope 'xrefvisit' def makexref(tree): Regenerating cross-reference database...Traceback (most recent call last): File scripts/kxref.py, line 540, in ? load_context(sourcetree) File scripts/kxref.py, line 492, in load_context (xrefs, cml1types) = makexref(tree) File scripts/kxref.py, line 221, in makexref os.path.walk(., xrefvisit, xrefdict) File /usr/lib/python2.1/posixpath.py, line 277, in walk walk(name, func, arg) File /usr/lib/python2.1/posixpath.py, line 269, in walk func(arg, top, names) File scripts/kxref.py, line 216, in xrefvisit filevisitor(dict, node) File scripts/kxref.py, line 191, in filevisitor symdef = definere.search(lines[0]) NameError: global name 'definere' is not defined ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] cml2-1.9.10 problems with kxref.py script
On Thursday 20 December 2001 11:58 am, Eric S. Raymond wrote: Steven Cole [EMAIL PROTECTED]: Results of cml2-1.9.11 and Python 2.1 after kxref.out is deleted: [snippage] NameError: global name 'definere' is not defined Aaarrgghh. I typoed. Apply this patch: Obviously correct patch snipped. That should make it run under all 2.x versions. Yep, that fixes it. A Kibithanks to you! Steven ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] CML2 1.9.9 possible problem with CONFIG_ATM_FORE200E derived symbol.
Hello all, I gave cml2-1.9.9 a try for 2.4.17-rc1 and got this new error (not present with cml1 and same starting .config): In file included from fore200e.c:61: fore200e.h:840:6: warning: #warning compiling the fore200e driver without any hardware support enabled! fore200e.c: In function `fore200e_send': fore200e.c:1522: `CONFIG_ATM_FORE200E_TX_RETRY' undeclared (first use in this function) fore200e.c:1522: (Each undeclared identifier is reported only once fore200e.c:1522: for each function it appears in.) fore200e.c: At top level: fore200e.c:253: warning: `fore200e_spin' defined but not used make[2]: *** [fore200e.o] Error 1 Snippet from config.out: # # Derived symbols # CONFIG_SUNRPC=n CONFIG_ATM_FORE200E=m- didn't want this. CONFIG_53C700_MEM_MAPPED=n CONFIG_LOCKD_V4=n CONFIG_MSNDPIN_HAVE_BOOT=n CONFIG_X86_GOOD_APIC=y My starting .config did not have anything related to the ATM_FORE200E* set, but cml2 sets CONFIG_ATM_FORE200E to m. Otherwise, a slightly smaller kernel was built, which I am running right now. 948 -rw-r--r--1 root root 964688 Dec 12 16:00 vmlinuz-2.4.17-pre8 948 -rw-r--r--1 root root 964716 Dec 14 08:04 vmlinuz-2.4.17-rc1 928 -rw-r--r--1 root root 945077 Dec 14 08:57 vmlinuz-2.4.17-rc1-cml2 Steven ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] CML2 1.9.9 possible problem with CONFIG_ATM_FORE200E derived symbol.
On Friday 14 December 2001 09:41 am, Steven Cole wrote: My starting .config did not have anything related to the ATM_FORE200E* set, but cml2 sets CONFIG_ATM_FORE200E to m. OK, here I go replying to myself. I looked at rules.cml in drivers/atm and saw this: derive ATM_FORE200E from ATM (ATM_FORE200E_MAYBE | m) unless ATM_FORE200E_PCA==n suppress ATM_FORE200E_PCA_FW unless ATM_FORE200E_SBA==n suppress ATM_FORE200E_SBA_FW require (ATM_FORE200E_MAYBE!=n and PCI) implies ATM_FORE200E_PCA == y derive ATM_IDT77252_USE_SUNI from ATM_IDT77252_RCV_ALL # Suppress some derivations unless ATM suppress ATM_FORE200E ATM_IDT77252_USE_SUNI I found that in my original .config, CONFIG_ATM was set, but since this is not needed, I used cml2 make xconfig to set it to n, and the subsequent build with make modules was error-free. Steven ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Python 2.0 (from Debian) and CML2 1.3.3?
On Friday 11 May 2001 15:15, Eric S. Raymond wrote: Jamie Fifield [EMAIL PROTECTED]: I've noticed some incompatibilities with CML2 1.3.3 and the Debian packaged Python 2.0 in woody. Is it safe to say that CML2 now requires Python 2.1? (If so, please update the weeeb page). [Jamie's bug report snipped] I'm extremely puzzled. Your bug report sounds definitive. Jeff Millar has reported similar symptoms. And yet I cannot reproduce them here. Look: [ESR's success report snipped] Just to add another data point, I'm using LM 8.0 RC1, and cml2-1.4.1 installs for me: [root@localhost cml2-1.4.1]# python Python 2.0 (#1, Mar 30 2001, 14:27:34) [GCC 2.96 2731 (Linux-Mandrake 8.0 2.96-0.47mdk)] on linux-i386 Type copyright, credits or license for more information. [root@localhost cml2-1.4.1]# ./install-cml2 /usr/src/linux-2.4.4 Examining your build environment... Good. You have Python 2.x installed as 'python' already. Python looks sane... Good, your python has curses support linked in. Good, your python has Tk support linked in. Compiling file list... Operating on /usr/src/linux-2.4.4... Installing new files... Merging in CML2 help texts from Configure.help... Duplicate help text for HISAX_ELSA_CS Duplicate help text for HISAX_SEDLBAUER_CS Duplicate help text for ISDN_CAPI_CAPI20 Duplicate help text for ISDN_CAPI_MIDDLEWARE Duplicate help text for ISDN_CAPI_CAPIFS_BOOL Duplicate help text for ISDN_CAPI_CAPIDRV Duplicate help text for ISDN_DRV_AVMB1_AVM_CS Modifying configuration productions... You are ready to go, cd to /usr/src/linux-2.4.4. And, by the way, contrary to other reports that no distros are shipping with Python 2.0, LM 8.0 certainly does, and 8.0 final also installs the tkinter package with the development workstation installation. Steven ___ kbuild-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] [PATCH] 2.4.3-ac13 update L: tags for two MAINTAINER entries
On Tuesday 24 April 2001 15:49, Michael Elizabeth Chastain wrote: Michael, is this correct for your entry? The state of Configure/Menuconfig/Xconfig is no longer Maintained. Orphan is more accurate. Also you can list http://kbuild.sourceforge.net as our web site. It has links to the mailing list archives. OK, I'll make a new patch for MAINTAINERS with the web site URL once the issue of one list or two is decided. The old torque.net address can definitely be retired, but I want to have a discussion first. Should we have a separate kbuild-user list for kbuild users, or should we have one unified list? [snipped] I'm in favor of a single unified list. If the developers get so many bug reports that they can't work on the next version, then they should improve the software or improve the documentation that goes with it. In particular, if lots of people experience usablility problems, then the docs usually need more work. But I'm interested in other people's opinions before making a decision. I agree with the above. Steven ___ kbuild-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/kbuild-devel
