Re: [kbuild-devel] Your opinion on CML2 and kbuild-2.5
Tom Rini [EMAIL PROTECTED]: Right now symbols without a help entry still won't show up unless CONFIG_ADVANCED is set (right?). And as a case in point (which I told Eric not to do), CONFIG_PPC_RTC is currently a derived symbol instead of being a question (and if I read the derivation right, it's wrong to boot). I must have missed some mail from you. If it's still incorrect in 2.3.0, I will fix it. -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a ___ 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
Tom Rini [EMAIL PROTECTED]: It's not so much the look feel (which seems to have been copied well by now), but policy changes. I'm glad you think I got the look and feel OK. If I were bug-for-bug compatible with the old system, there would hardly be any point, would there? I'm not ignoring your point at all. But saying don't make policy changes is easy to do, knowing where the boundary between policy and design bugs falls is rather harder. I'm not going to refrain from fixing design bugs because some people might think they are policy -- in many cases there was never any decision or thought about the alleged policy. You want the PPC_RTC thing fixed. I'll do that. What else do *you* need? -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a ___ 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
Tom Rini [EMAIL PROTECTED]:
Strictly stated implication for strictly stated implication?
Can't do that, either. One major reason is the single-apex menu tree.
Another is that the old language didn't carry enough information to
do side-effect forcing properly.
What invariant or behavior are you trying to preserve with no additional
restrictions? Most of the additional restrictions are bus guards, so that
(for example) users won't see EISA questions on a non-EISA system. Is this
a bad thing?
Well, if there wasn't an EISA guard for CML1, there should't be for CML2
_yet_. Why? It's either an intentional feature (it's actually EISA and
some wierd bus from {arm,ppc,cris,other}) or it's a bug that should be
submitted seperately so someone can pop up and say it's wrong or not.
There's an underlying concern that if it's not a rather strict
translation of the current rules, there's bugs, and people don't want to
fix bugs that don't exist in the current system.
Well...all I can say to this is that I have beta-testers regularly sending
me rulesfile fixes, but they're all pretty minor stuff. If the logical
mapping between old and news spec were seriously broken, I would not
be able to avoid knowing it.
--
a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a
___
kbuild-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Your opinion on CML2 and kbuild-2.5
kbuild team members: Dirk Hohndel has volunteered to have a chat with Linus about the CML2/kbuild-2.5 transition (and, implicitly, the status and role of the kbuild team). Please inform him of: 1) your technical judgement and opinions about CML2 and kbuild-2.5 2) the problems with the present build system, 3) whether or not you think CML2 and kbuild-2.5 should be mainstreamed into the kernel, 4) known remaining problems with CML2 and kbuild-2.5, and what the plans are to address them. He needs to hear from the whole kbuild team and properly understand the background of our present rather frustrating situation. -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a If gun laws in fact worked, the sponsors of this type of legislation should have no difficulty drawing upon long lists of examples of criminal acts reduced by such legislation. That they cannot do so after a century and a half of trying -- that they must sweep under the rug the southern attempts at gun control in the 1870-1910 period, the northeastern attempts in the 1920-1939 period, the attempts at both Federal and State levels in 1965-1976 -- establishes the repeated, complete and inevitable failure of gun laws to control serious crime. -- Senator Orrin Hatch, in a 1982 Senate Report ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] CML2-2.1.7 is available
The latest version is always available at http://www.tuxedo.org/~esr/cml2/. Release 2.1.7: Tue Jan 22 09:04:22 EST 2002 * Resync with 2.5.3-pre3. * Complete hardware probes for MCA by David Weinehall (untested). * By popular demand, `make autoconfigure' is now `make autoconfig'. I'm back from ConFusion. Ordinary checkpoint release. -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a During waves of terror attacks, Israel's national police chief will call on all concealed-handgun permit holders to make sure they carry firearms at all times, and Israelis have many examples where concealed permit holders have saved lives. -- John R. Lott Conservatism is the blind and fear-filled worship of dead radicals. ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: CML2-2.1.3 is available
Ross Vandegrift [EMAIL PROTECTED]: 1) I noticed you've been pining the lists for EISA information. I don't know a whole lot about EISA systems or anything, but I do have a 486 EISA board and an EISA network card I'd be willing to send you if you wanted a system to play around with. I don't use it anymore and it's just gathering dust in my basement. Thanks for the offer, but the question I was after has been answered. 2) It seems that searching is broken. Got it, I think I've fixed this. -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a Nearly all men can stand adversity, but if you want to test a man's character, give him power. -- Abraham Lincoln ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: CML2-2.1.3 is available
David Woodhouse [EMAIL PROTECTED]: Hmmm, yes. I think I see at least two errors in that small selection, if I understand it correctly. Please help me correct them. But as these are obviously behavioural changes, and you've said you won't make behavioural changes in the first push of CML2 to Linus, we can safely ignore them for now - they're lined up for your second wave of patches, right? The definition of behavioral change you're implying here is so narrow that if I interpreted the agreement that way, CML2 could do nothing worthwhile. Get real, please. -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a The danger (where there is any) from armed citizens, is only to the *government*, not to *society*; and as long as they have nothing to revenge in the government (which they cannot have while it is in their own hands) there are many advantages in their being accustomed to the use of arms, and no possible disadvantage. -- Joel Barlow, Advice to the Privileged Orders, 1792-93 ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: CML2-2.1.3 is available
David Woodhouse [EMAIL PROTECTED]: Utter crap. CML2 makes them possible, and is a step in the right direction. I'm not suggesting that you never make these changes - just that you do them separately from the change in mechanism. Sorry, it's *way* too late for that. In fact, it was already way too late for that at the kernel summit last March when Linus issued his ukase. The change in mechanism phase of the project was essentially complete almost a year ago now. If you had been paying attention, you would have noticed this. The idea that a pure change in mechanism could ever have been cleanly separated from changes in behavior was a fantasy anyway. Large changes in a software architecture just don't work that way, as we rediscover every time a significant subsystem gets reworked to fix bugs. I have held off on many things that I think badly need to be done in order to pacify the conservative instincts of people like yourself -- for example, I think the device menus cry out to be reorganized on a functional basis rather than on the basis of internal distinctions like block vs. character devices that are pointless to anyone but a kernel implementor. But if attempting that implausibility of no behavioral changes is what you think I agreed to, we'd best both forget the agreement -- because it would be hypocrisy if I agreed falsely and an absurd, project-strangling shackle if I agreed sincerely. Continuity, avoiding gratuitous changes, and a good-faith effort to emulate the interfaces people are expecting is one thing; artificial stasis is entirely another. I'm doing my best to give you the former. You won't get the latter, no way, nohow. If you have spotted errors, the time to tell me about them is *now*. It's unfair to me and to other developers to artificially hold off until we pass some mythical point at which it will suddenly be OK for behavior to change. The real world doesn't work that way, and I am sure you are too experienced to believe it does. -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a If a thousand men were not to pay their tax-bills this year, that would ... [be] the definition of a peaceable revolution, if any such is possible. -- Henry David Thoreau ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] CML2-2.1.6
The latest version is always available at http://www.tuxedo.org/~esr/cml2/. Release 2.1.6: Thu Jan 17 09:42:47 EST 2002 * Oops. Allow rulebases without a prefix declaration. * Autoconfigurator now has MCA-bus test. Checkpoint release before I go to an SF convention for four days, without net access gConFusion here I come! -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a As the Founding Fathers knew well, a government that does not trust its honest, law-abiding, taxpaying citizens with the means of self-defense is not itself worthy of trust. Laws disarming honest citizens proclaim that the government is the master, not the servant, of the people. -- Jeff Snyder ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] CML2-2.1.4 is available
The latest version is always available at http://www.tuxedo.org/~esr/cml2/. Release 2.1.4: Wed Jan 16 14:42:57 EST 2002 * Resync with 2.4.18-pre4 and 2.5.3-pre1. * Fixed a nasty little bug in property computation. * Fixed another nasty little bug in display of constraint violations. I fat-fingered some display code in 2.1.3 while trying to do a better job of passing rulesfile line number information back in error popups. This patch fixes that problem. The autoconfigurator is progressing nicely. It now generates a correct configuration in Look, ma! No hands. mode on three different Intel boxes -- my all-PCI SCSI custom monster machine, an IDE-based IBM Thinkpad laptop, and a hybrid PCI/ISA VA box from late '97. -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a The conclusion is thus inescapable that the history, concept, and wording of the second amendment to the Constitution of the United States, as well as its interpretation by every major commentator and court in the first half-century after its ratification, indicates that what is protected is an individual right of a private citizen to own and carry firearms in a peaceful manner. -- Report of the Subcommittee On The Constitution of the Committee On The Judiciary, United States Senate, 97th Congress, second session (February, 1982), SuDoc# Y4.J 89/2: Ar 5/5 ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: CML2-2.1.3 is available
Horst von Brand [EMAIL PROTECTED]: Release 2.1.3: Tue Jan 15 14:41:45 EST 2002 * Resync with 2.4.18-pre3 and 2.5.2. * It is now possible to declare explicit saveability predicates. * The `vitality' flag is gone from the language. Instead, the autoprober detects the type of your root filesystem and forces its symbol to Y. Great! Now I can't configure a kernel for ext3 only on an ext2 box. Keep it up! As it goes, we can safely forget about CML2... Oh, nonsense. You can do this just fine with any of the manual configurators. Now repeat after me, Horst: The autoconfigurator is *optional*, not required. The autoconfigurator is *optional*, not required. The autoconfigurator is *optional*, not required. The autoconfigurator is *optional*, not required. The autoconfigurator is *optional*, not required. : : : : : Please continue until insight penetrates your skull. Thank you. -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects. -- Robert A. Heinlein, Time Enough for Love ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: CML2-2.1.3 is available
Horst von Brand [EMAIL PROTECTED]: Whatever happened to Do exactly as CML1 does; leave fixes and extensions for later? If you put the kitchen sink into it, it _won't_ go into the standard kernel. If you stick to the CML1-equivalent facilities, you'll get almost CML1-equivalent behavior. It's almost partly because the hardware symbols have more platform- and bus-type guards than they used to -- but mostly because I have not emulated the numerous CML1 bugs. -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a The people cannot delegate to government the power to do anything which would be unlawful for them to do themselves. -- John Locke, A Treatise Concerning Civil Government ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: CML2-2.1.4 is available
Ross Vandegrift [EMAIL PROTECTED]: On Wed, Jan 16, 2002 at 02:56:05PM -0500, Eric S. Raymond wrote: I've verified that the lockup I reported earlier still happens with 2.1.4. Keystroke sequence to reproduce, please? -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a Taking my gun away because I might shoot someone is like cutting my tongue out because I might yell `Fire!' in a crowded theater. -- Peter Venetoklis ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: CML2-2.1.4 is available
Ross Vandegrift [EMAIL PROTECTED]: On Wed, Jan 16, 2002 at 05:43:40PM -0500, Eric S. Raymond wrote: Ross Vandegrift [EMAIL PROTECTED]: On Wed, Jan 16, 2002 at 02:56:05PM -0500, Eric S. Raymond wrote: I've verified that the lockup I reported earlier still happens with 2.1.4. Keystroke sequence to reproduce, please? ENTER On what screen? With the tool invoked how? -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a No matter how one approaches the figures, one is forced to the rather startling conclusion that the use of firearms in crime was very much less when there were no controls of any sort and when anyone, convicted criminal or lunatic, could buy any type of firearm without restriction. Half a century of strict controls on pistols has ended, perversely, with a far greater use of this weapon in crime than ever before. -- Colin Greenwood, in the study Firearms Control, 1972 ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: CML2-2.1.3 is available
David Woodhouse [EMAIL PROTECTED]: I'm concerned by the 'platform- and bus-type guards' to which you refer. Could you give some examples where the behaviour has changed? Lots of embedded non-x86, non-ISA boxen have ISA network chips glued in somehow, for example. I hope you haven't helpfully stopped that from working. No, I haven't. Wha's happened is that I, and others, have merged in a lot of information about what cards can be plugged into which platforms. That information has been turned into dependency/visibility rules. The generic hardware that can be used on several platforms has bus guards. The on-board hardware has platform guards. Some cards that can only be used in single-platform buses have platform guards as well. Here are some examples from the network cards... Bus guards: unless MCA suppress dependent ELMC ELMC_II ULTRAMCA SKMC NE2_MCA IBMLANA unless ISA_CLASSIC suppress EL1 EL2 ELPLUS EL16 WD80x3 APOLLO_ELPLUS unless ISA_PNP suppress CONFIG_3C515 unless EISA suppress dependent LNE390 NE3210 unless ISA_CLASSIC or EISA suppress AC3200 unless ISA_CLASSIC or ISA_PNP!=n or EISA or MCA suppress EL3# 3c509 source unless EISA or PCI or CARDBUS!=n suppress VORTEX# Vortex help screen unless ISA_CLASSIC or ISA_PNP!=n or PCI suppress LANCE # Lance source unless SPARC or SPARC64 suppress SUNLANCE unless EISA suppress dependent ULTRA32 # SMC-ULTRA32 unless PCI suppress dependent PCNET32 DE2104X TULIP EEPRO100 NE2K_PCI CONFIG_8139TOO CONFIG_8139TOO_8129 WINBOND_840 HAPPYMEAL ADAPTEC_STARFIRE FEALNX NATSEMI VIA_RHINE EPIC100 SUNDANCE unless ISA_CLASSIC suppress dependent NI52 NI65 unless EISA or PCI suppress DE4X5 DGRS DM9102 TLAN unless ISA_CLASSIC or EISA or MCA suppress DEPCA#depca.c unless ISA_CLASSIC or EISA or MCA suppress HP100 unless ISA_CLASSIC or MCA suppress AT1700 #at1700.c unless ISA_CLASSIC suppress dependent NI5010#ni5010.c unless ISA_CLASSIC suppress dependent E2100 EWRK3 EEXPRESS EEXPRESS_PRO FMV18X HPLAN HPLAN_PLUS ETH16I SEEQ8005 SK_G16 ES3210 APRICOT unless ISA_CLASSIC or ISA_PNP suppress NE2000 unless ISA_PNP suppress ULTRA unless ISA_PNP or CARDBUS suppress I82365 Platform guards: unless SGI_IP27 or IA64_SGI_SN1 suppress SGI_IOC3_ETH unless X86 suppress dependent ATP unless X86 or ALPHA or PPC suppress NET_VENDOR_3COM unless X86 or ALPHA suppress LANCE NET_VENDOR_SMC NET_VENDOR_RACAL unless SPARC suppress dependent HAPPYMEAL SUNBMAC SUNQE unless DECSTATION suppress dependent DECLANCE unless BAGET_MIPS suppress dependent BAGETLANCE unless (CONFIG_8xx or CONFIG_8260) suppress SCC_ENET FEC_ENET ENET_BIG_BUFFERS unless AMIGA and PCMCIA!=n suppress dependent APNE unless APOLLO suppress dependent APOLLO_ELPLUS unless MAC suppress dependent MAC8390 MACSONIC SMC9194 MAC89x0 MACMACE CS89x0 unless ATARI suppress dependent ATARILANCE unless SUN3X or SPARC suppress SUN3LANCE unless SUN3 suppress dependent SUN3_82586 unless HP300 suppress dependent HPLANCE unless SUPERH suppress dependent STNIC Compound bus *and* platform guard: unless (X86 or ALPHA) and PARPORT!=n suppress dependent NET_POCKET In a typical situation, you're going to enable platform and bus symbols early. All these guards will drastically filter the questions you have to answer later. The overall objective is to reduce the questions a human user asks to those strictly relevant to his or her configuration. Now we're closing in on the second-stage objective, which is to automatically discover (via an *optional* program...kids, remember that word *optional*) so much about the configuration that the user need only answer questions that are genuinely about policy and capabilities. -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a The conclusion is thus inescapable that the history, concept, and wording of the second amendment to the Constitution of the United States, as well as its interpretation by every major commentator and court in the first half-century after its ratification, indicates that what is protected is an individual right of a private citizen to own and carry firearms in a peaceful manner. -- Report of the Subcommittee On The Constitution of the Committee On The Judiciary, United States Senate, 97th Congress, second session (February, 1982), SuDoc# Y4.J 89/2: Ar 5/5 ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Re: CML2-2.1.4 is available
Ross Vandegrift [EMAIL PROTECTED]: Sorry, didn't mean to be so terse. Same as before - 'make config' or 'make menuconfig', press enter upon being shown the main menu while the default selection is Intel or Processor type (FROZEN). Got it. Looks like a bug I introduced when I filled someone else's request to make frozen symbols invisible two point releases ago. I should have it fixed tonight. -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a The danger (where there is any) from armed citizens, is only to the *government*, not to *society*; and as long as they have nothing to revenge in the government (which they cannot have while it is in their own hands) there are many advantages in their being accustomed to the use of arms, and no possible disadvantage. -- Joel Barlow, Advice to the Privileged Orders, 1792-93 ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] cml2-2.1.3 bug report
jeff millar [EMAIL PROTECTED]: 2. Something triggers the building of everything modular, like _all_ the network cards, I2O, IEEE1394, etc. You implied in an earlier email that selecting modules leads to this. But, I just want to build a few modules because it takes less time and disk space and it easier to audit /lib/modules/2.4.x/ results. Besides with bleeding edge kernels, often lots of drivers don't compile correctly. My original .config has m where I want it and setting m a bunch more places means I just have to go around and shut off hundreds of things. This should only happen if you used `make autoconfigure'. Did you? -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a The right of self-defense is the first law of nature: in most governments it has been the study of rulers to confine this right within the narrowest limits possible. Wherever standing armies are kept up, and when the right of the people to keep and bear arms is, under any color or pretext whatsoever, prohibited, liberty, if not already annihilated, is on the brink of destruction. -- Henry St. George Tucker (in Blackstone's Commentaries) ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] CML2-2.1.3 is available
The latest version is always available at http://www.tuxedo.org/~esr/cml2/. Release 2.1.3: Tue Jan 15 14:41:45 EST 2002 * Resync with 2.4.18-pre3 and 2.5.2. * It is now possible to declare explicit saveability predicates. * The `vitality' flag is gone from the language. Instead, the autoprober detects the type of your root filesystem and forces its symbol to Y. The interactive configurators remain stable; no bugs of any kind have been reported since 6 Jan. I'm waiting on an update of the probe tables from Giacomo Catenazzi before releasing 2.2.0. -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a Under democracy one party always devotes its chief energies to trying to prove that the other party is unfit to rule--and both commonly succeed, and are right... The United States has never developed an aristocracy really disinterested or an intelligentsia really intelligent. Its history is simply a record of vacillations between two gangs of frauds. --- H. L. Mencken ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: CML2-2.1.3 is available
Nicolas Pitre [EMAIL PROTECTED]: Release 2.1.3: Tue Jan 15 14:41:45 EST 2002 * The `vitality' flag is gone from the language. Instead, the autoprober detects the type of your root filesystem and forces its symbol to Y. What happens if you compile a kernel for another machine? Or cross-compile? In that case you can't use the autoconfigurator anyway. You're going to have to make sure by hand that the controller, bus type, and file system code for your root device are hard-compiled in. (This is at least no worse off than you were under CML1.) Rob Landley pointed out correctly that the vitality flag was not actually solving this problem, and it was an ugly wart on the language. Instead, there's a symbol property BOOTABLE in the new rulebase that is attached to IDE and SCSI hardware symbols that are controllers for what could be boot devices. One of the remaining limitations of the autoconfigurator is that it only knows how to detect IDE and SCSI boot devices. I want to be able to make it nail NFS and USB storage being used as root, but it's not there yet. -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a The American Republic will endure, until politicians realize they can bribe the people with their own money. -- Alexis de Tocqueville ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: CML2-2.1.3 is available
Rob Landley [EMAIL PROTECTED]: Eric and I disagree on the behavior of make autoprobe. He likes the concept of freezing symbols, which says if the autoprober detected a configuration setting, the question shouldn't show up and give you the opportunity to disagree. (Not confusing Aunt Tillie, with her LCSE from CompTIA (and apparently has recently moved in with Alan Cox), with questions that she's more likely to screw up than improve.) Note, everyone else, that the freezing only happens on make autoprobe. The config.out that make autoconfigure writes is not frozen. Personally, I think that if you turn on expert mode, you should be able to override anything. I haven't complained much because there is an easy workaround: Although the autoprober puts the frozen flag on the symbols it finds, menuconfig doesn't save them out :). Correction: menuconfig *does* save out frozen symbols, but it saves them unfrozen. So just run menuconfig twice and you can edit everything that got autoprobed... This workaround is entirely intentional. (Now the standard configuration DOES freeze, and therefore hide, the which architecture am I building for question. It would be nice if make menuconfig would let you do a cross-compile simply by selecting your architecture. I understand why this isn't supported though: to properly build most architectures other than X86, you have to apply patches to Linus's tree. And the make would have to tell gcc to cross-compile, which most gcc builds don't know how to do and the makefiles don't seem to support anyway...) Actually, this kind of cross-configuration is already fully supported. The normal way of calling the configurator, through the Makefile, passes -D$(ARCH) -- but if you call it without an architecture symbol frozen by command-line option, architecture will be the first question you're asked. -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a All forms of government are pernicious, including good government. -- Edward Abbey ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] CML2-2.1.2 is available
The latest version is always available at http://www.tuxedo.org/~esr/cml2/. Release 2.1.2: Fri Jan 11 03:50:36 EST 2002 * Resync with 2.5.2-pre11. * Properties introduced. Symbols can now have associated class flags. to be used by configurator programs. * Frozen symbols are no longer visible. Checkpoint release. The compiler has just undergone major surgery, so this one may be a bit buggier than typical recently (though it passed all my standard tests). I'm in the throes of introducing property-annotation macinery for use by the autoconfigurator. -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a The United States is in no way founded upon the Christian religion -- George Washington John Adams, in a diplomatic message to Malta. ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] CML2-2.1.1 is available
The latest version is always available at http://www.tuxedo.org/~esr/cml2/. Release 2.1.1: Wed Jan 9 22:28:17 EST 2002 * Autoconfigurator tables now have PRIORITY declaration for resolving multiple drivers being enabled by the same probe. * Pychecker cleanup of everything. Checkpoint release. I'm about to add some new capabilities to the language for the autoconfigurator. -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a As war and government prove, insanity is the most contagious of diseases. -- Edward Abbey ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] CML2-2.0.4 is available
The latest version is always available at http://www.tuxedo.org/~esr/cml2/ Release 2.0.4: Tue Jan 8 22:55:43 EST 2002 * Rulebase and help sync with 2.4.18-pre2/2.5.2-pre10. * kxref.py can report dependency/ancestry relationships and label status now. * More autoconfigurator improvements, including --standalone option. Bug queue is empty. The compiler and interactive configurators are looking stable at this point; most of my effeort is going into improving the autoconfigurator. -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects. -- Robert A. Heinlein, Time Enough for Love ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: Hardware Inventory [was: Re: ISA slot detection on PCI systems?]
Greg KH [EMAIL PROTECTED]: On Mon, Jan 07, 2002 at 10:50:01AM -0800, Greg KH wrote: And the /sbin/hotplug program knows about _all_ devices that the currently compiled kernel can handle due to the MODULE_DEVICE_TABLE tags in the drivers. Along these lines, I am very disappointed in looking at the autoconfigure stuff in CML2. It should be taking all of the device and driver matching information from the kernel itself, as it is already specified there. I'm taking my rules file from Giacomo Catenazzi, who developed it originally for a shellscript he wrote. I don't know how he generates the hardware probes; for all I know, he's got code groveling through the module device tables. I've been meaning to ask you about this, Giacomo. Where *did* all those probes come from? -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a Don't think of it as `gun control', think of it as `victim disarmament'. If we make enough laws, we can all be criminals. ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] CML@-2.0.3
Release 2.0.3: Sun Jan 6 19:04:28 EST 2002 * Massive autoprobe rules update by Giacomo. * Vital symbols (those that are critical, like disk drivers for potential root devices) are now forced to Y when the autoconfigurator finds their hardware. The autoconfigurator is much snmarter now, but running a manual configure afterwards is recommended. This release also fixes a bug in field entry of hexadecimal symbol values. -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a Since there is no such entity as 'the public,' since the public is merely a number of individuals, the idea that 'the public interest' supersedes private interests and rights can have but one meaning: that the interests and rights of some individuals take precedence over the interests and rights of others. -- Ayn Rand ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] CML2-2.0.1 -- brown-paper-bag-bug fix
The latest version is always available at http://www.tuxedo.org/~esr/cml2/ Release 2.0.1: Sat Jan 5 18:41:47 EST 2002 * The now-traditional fix for the now-traditional brown-paper-bag major release. * Rulebase and help sync with 2.4.18-pre1/2.5.2-pre8. Sigh...I don't know how my tests failed to catch that elementary type-composition error. But at least I can console myself with the thought that I am following in the footsteps of greatness. -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a ...quemadmodum gladius neminem occidit, occidentis telum est. [...a sword never kills anybody; it's a tool in the killer's hand.] -- (Lucius Annaeus) Seneca the Younger (ca. 4 BC-65 AD), ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: ISA slot detection on PCI systems?
Andrew Morton [EMAIL PROTECTED]: If Eric can get the entire download-config-build-install process down to a single mouse click, he'll have done us all a great service. Single-mouse-click configuration isn't going to happen soon. It may not happen at all. However, I believe pushing in that direction is worthwhile. Configuration *can* be made a helluva lot easier than it is now. Easier than I think most kernel developers would believe possible, at least before sitting down to a serious think and abandoning a lot of long-held assumptions about how things `have' to be. CML2 was the first step. It gives us a tool that can guarantee the correctness and consistency of configuration changes according to a rulebase. The autoconfigurator that Giacomo Catenazzi started, which I am now integrating with CML2, is the next step. I expect it to reduce the task complexity for typical configuration cases by 90%. It's pretty effective, including more than 2500 probes. I don't know what the third step will be yet. It depends partly on what that remaining 10% looks like. -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a Experience should teach us to be most on our guard to protect liberty when the government's purposes are beneficient...The greatest dangers to liberty lurk in insidious encroachment by men of zeal, well meaning but without understanding. -- Supreme Court Justice Louis Brandeis ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] CML2-1.9.20
The latest version is always available at http://www.tuxedo.org/~esr/cml2/ Release 1.9.20: Mon Dec 31 12:33:41 EST 2001 * Corrected a rulebase bug that prevented proper initialization in some cases. This should make life easier for the beta testers. -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a The people cannot delegate to government the power to do anything which would be unlawful for them to do themselves. -- John Locke, A Treatise Concerning Civil Government ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Re: State of the new config build system
Russell King [EMAIL PROTECTED]: On Sat, Dec 29, 2001 at 05:43:54PM -0500, Eric S. Raymond wrote: Tom Rini [EMAIL PROTECTED]: unless (ISA or PCI) suppress dependent IDE Just a minor point, but what about non-PCI/ISA ide? The CML1 rules seem to imply that this set is empty. RiscPC: CONFIG_PCI=n CONFIG_ISA=n CONFIG_ARCH_ACORN=y Yet, we have in drivers/ide: if [ $CONFIG_ARCH_ACORN = y ]; then dep_bool 'ICS IDE interface support' CONFIG_BLK_DEV_IDE_ICSIDE $CONFIG_ARCH_ACORN dep_bool ' ICS DMA support' CONFIG_BLK_DEV_IDEDMA_ICS $CONFIG_BLK_DEV_IDE_ICSIDE dep_bool 'Use ICS DMA by default' CONFIG_IDEDMA_ICS_AUTO $CONFIG_BLK_DEV_IDEDMA_ICS define_bool CONFIG_BLK_DEV_IDEDMA $CONFIG_BLK_DEV_IDEDMA_ICS dep_bool 'RapIDE interface support' CONFIG_BLK_DEV_IDE_RAPIDE $CONFIG_ARCH_ACORN fi So I guess I've found a bug. I have removed the constraint in question. -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a Let us hope our weapons are never needed --but do not forget what the common people knew when they demanded the Bill of Rights: An armed citizenry is the first defense, the best defense, and the final defense against tyranny. If guns are outlawed, only the government will have guns. Only the police, the secret police, the military, the hired servants of our rulers. Only the government -- and a few outlaws. I intend to be among the outlaws. -- Edward Abbey, Abbey's Road, 1979 ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] autoconfigure.sh and cmlconfigure.py design philosophy
I have been looking at Giacomo's autoconfigure.sh code and thinking about it should communicate with CML2. I like the concept, and the implementation starting from a table of probe routines calls in a rules file is clever. Unfortunately, as the program is now it yields mostly information about what is present on the system, not information about hardware and features that are known *not* to be present. To reduce the complexity of the user's configuration task to a minimum, autoconfigure.sh should not merely be able to list (for example) all the PCI hardware on the system, it should also be able to assert that the symbols for all *other* PCI hardware should be frozen to `n' so so none of those questions will ever be asked. Similar considerations obtain for any bus with a registry (such as I2O), but PCI is the most important case so I'll keep using it as an example. The design question then becomes this: who knows what the set of all PCI devices is, and computes the complement of the set of detected devices? There are several possible answers to this question. Each has different design implications. autoconfigure.sh itself could compute the set complement. This implies that either (a) autoconfigure.sh itself would have to contain a list of all symbols dependent on PCI or (b) such a list would have to live in the autoconfigure.rules file. Both these design choices would be poor. The major problem is that either would duplicate knowledge already present in the configuration rulebase, probably leading to inconsistencies and certainly creating an unpleasant maintainance task. This leads us directly to the second possibility, that autoconfigure.sh could read the configuration rulebase and use that information to compute the complement set. This could work in one of two ways: either (a) autoconfigure.sh could process the pickled CML2 rulebase itself (in which case it would have to be rewritten at least partly in Python) or (b) autoconfigure.sh could call an agent program to generate the list for it (adding an option to kxref.py to do this would be nearly trivial). There is a third possibility. autoconfigure.sh is going to pass its results to cmlconfigure.py in a file with the format of a config.out. Right now all those results are symbol bindings (FOO=y, BAR=n). Conceivably autoconfigure.sh could also pass a directive like finished PCI which would tell cmlconfigure.py that all PCI-dependent symbols not yet set should be set to `n'. Either of these alternatives (autoconfigure.sh querying the rulebase or passing a directive to cmlconfigure.py) could work nicely. Which is the right thing is really a question of design philosophy -- that is, what do we *want* the roles of autoconfigure.sh and cmlconfigure.py to be? And how closely coupled should they be? I don't have strong opinions on either question. But I want to get them on the table so we'll think about them at a design level before rushing to code. -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a Rifles, muskets, long-bows and hand-grenades are inherently democratic weapons. A complex weapon makes the strong stronger, while a simple weapon -- so long as there is no answer to it -- gives claws to the weak. -- George Orwell, You and the Atom Bomb, 1945 ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: State of the new config build system
Linus Torvalds [EMAIL PROTECTED]: My pet peeve is centralized knowledge. I absolutely detested the first versions of cml2 for having a single config file, and quite frankly I don't think Eric has even _yet_ separated things out enough - why does the main rules.cml file have architecture-specific info, for example? I'm not certain what you're objecting to, and I want to understand it. There are rules that use architecture symbols to suppress things like bus types. I presume that's not a problem for you, but tell me if it is. My best guess is that you're objecting to the archihacks and kernelhacking menus, or the architecture-dependent derivations down around line 330. In general what's going on here is actually the beginnings of an attempt to replace architecture-dependent questions with architecture-*independent* questions. It looks kind of ugly right now because it's too early in the game to mess with the config-symbol namespace -- but, for example, I want to merge the MATH_EMULATION and MATHEMU symbols eventually. And there ought to be a generic set of toggles for kernel-debugging that present to the user as cross-platform capabilities rather than platform- specific switches. In those two menus I've gathered together architecture-specific symbols that I think ought to merge into cross-platform capabilities. But I know there is other cruft in there for historical reasons. Since you've brought up the point, I'll do a cleanup pass on these and see how much I can exile to the arch/*/rules.cml files. There isn't really any help for the ceoss-platform derivations. There are exactly four of these. I've worked hard at holding them to a minimum: derive HAVE_DEC_LOCK from (SMP and (ALPHA or X86_CMPXCHG)) or SPARC or PPC derive HIGHMEM from HIGHMEM4G or HIGHMEM64G or SPARC derive MAC_HID from (ALL_PPC and INPUT!=n) or (MAC and INPUT_ADBHID) derive PC_KEYB from ARM_PC_KEYB or MIPS_PC_KEYB If you notice that each right-hand part includes port symbols from at least two different architectures, I think it will be clearer why these are necessary. CML1's way of doing this had the problem that it was hard to know by inspection of the rulebase under what circumstances a given symbol was actually turned on. This is why CML2 has a rule that each symbol is derived (or occurs in a menu) exactly once. With some work I could relax this restriction, but I don't want to -- it's a major factor in keeping the rulebase's complexity down in the range that a human brain can mentally model. That's a big step backwards as far as I'm concerned - we didn't use to have those stupid global files, and each architecture could do it's own config rules. Eric never got the point that to me, modularity is _the_ most important thing for maintenance. Oh, no, I got that all right. What I have been trying to do is trade off correctly between modularity (which helps maintenance) and the advantages to the configurator *users* of having a global capability namespace, single-apex menu structure, and the symbols-to-prompts mapping in one file. These choices weren't made at random. You don't readily see their advantages because you have a nose-to-the-code, maintainer perspective (quite properly so, in most cases). But in designing the configuration system, simplifying life for *users* is just as important, if not more so. Sometimes this implies not going as far in the direction you favor direction as you might like (monolithic Configure.help is an example). Something I also asked for the config system at least a year ago was to have Configure.help split up. Never happened. It's still one large ugly file. Driver or architecture maintainers still can't just change _their_ small fragment, they have to touch a global file that they don't own. Yes, there are two reasons for this. The contingent, historical reason is that I wanted to get Configure.help in good shape before thinking about dispersing it. That work is now done (though you haven't kept up to date with it). The design reason is that having a single file with all the symbol-to-prompt mappings in it is really helpful when you want to localize the rulebase for another language. I'm still leaning towards keeping symbols.cml together just to make it easier for people to do and distribute translations of it. I think this is an issue that is rising in importance. I have no problem with assuming that kernel hackers are English-literate, but it's no longer an assumption we should make about people *building* kernels. I want to encourage CML2 and question-string localizations for French. And German. And Thai. And Ethiopian. -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a If I were to select a jack-booted group of fascists who are perhaps as large a danger to American society as I could pick today, I would pick BATF [the Bureau of Alcohol, Tobacco, and Firearms]. -- U.S. Representative John Dingell, 1980
Re: [kbuild-devel] autoconfigure.sh and cmlconfigure.py design philosophy
Giacomo A. Catenazzi [EMAIL PROTECTED]: 1) From CML2 rules I derive all symbols that depends on some rules. The new tables are included in autoconfigure.sh This can be done in Makefile, so the symbols are always updated, and the autoconfigure is still simple shell, so it can be run to the TARGET machine. (easy ? python script). Yes, pretty easy. Or you could just hack autoconfigure.sh itself into Python and access the rulebase pickle directly. 2) I give CML2 some rules, and set the symbols (not already set) according to these rules. (complex hack in CML2 ?) Yes, quite complex. The problem is that adding new rules is something you have to invoke the compiler for, and it would involve mutating the rulebase pickle. I don't want to go that route. -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a The whole aim of practical politics is to keep the populace alarmed (and hence clamorous to be led to safety) by menacing it with an endless series of hobgoblins, all of them imaginary. -- H.L. Mencken ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: State of the new config build system
Alexander Viro [EMAIL PROTECTED]: I think this is an issue that is rising in importance. I have no problem with assuming that kernel hackers are English-literate, but it's no longer an assumption we should make about people *building* kernels. I want to encourage CML2 and question-string localizations for French. And German. And Thai. And Ethiopian. You are nuts. OK, you've got these translations. Now what? $FOO adds a new option. Should he, by any chance, supply all relevant translations in the same patch? No? No. The usual way to handle this, of course, is to fall back on the English where you don't have translations. Imperfect, but liveable. Good, so we are going to have them permanently out of sync. Better yet, option changes its meaning. Now we have English variant with new semantics and Thai one with the old. Happy, happy, joy, joy... Which is why there are organized translation groups that do periodic translation updates for software that has registered with them. This doesn't eliminate the problem, but it can keep it within manageable bounds that make having localizations better than not. I deal with this regularly with respect to fetchmail. Anyway, options change semantics only very rarely in the kernel rulebase. Trust me on this as I've been maintaining the CML2 rulebase for 18 months; I have a better handle on the frequency of these events than *anyone* else. You are worrying about a non-problem in this case. And that's aside of the real problem with internationalization - quality of translations _sucks_. Always. No, not always. I read French, Italian, and Spanish; I can puzzle out technical prose in a couple of other languages. I can read fetchmail's .po files and *see* that they don't suck. Frankly, I find it very amusing that advocates of i18n efforts tend to be either British or USAnians. That's not my experience. I've had technical problems with GNU gettext (unrelated to quality of translation) severe enough that I've come very close to dropping localization support twice. The people who plead with me not to drop it have been non-Anglophones. It may be that the reason our experiences have been different is because we focus on different target languages. But I think my experience is an existence proof that there *is* demand for localization and that meeting it can have useful results. -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a I do not find in orthodox Christianity one redeeming feature. -- Thomas Jefferson ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: State of the new config build system
Legacy Fishtank [EMAIL PROTECTED]: For single-file drivers, I like Becker's (correct credit?) system... about 10 lines of metadata is embedded in a C comment, and it includes the Config.in and Configure.help info. I proposed implementing something like this about a year ago (to replace the nasty centralized knowledge in the MAINTAINERS and CREDITS files) and was shot down. I'd be happy to take another swing at this problem once the kbuild-2.5/CML2 transition is done. But I don't think we should let it block us from having the good results we can get from that change. -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a Those who make peaceful revolution impossible will make violent revolution inevitable. -- John F. Kennedy ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: State of the new config build system
Linus Torvalds [EMAIL PROTECTED]: On Fri, 28 Dec 2001, Eric S. Raymond wrote: I'm not certain what you're objecting to, and I want to understand it. There are rules that use architecture symbols to suppress things like bus types. I presume that's not a problem for you, but tell me if it is. It _is_ a problem for me, because I want to do diffstat on a patch from a PPC maintainer, and if I see anything non-PPC, loud ringing noises go off in my head. I want that diffstat to say _only_ arch/ppc/... include/asm-ppc/... and nothing else. That way I know that I don't have to worry. Perhaps we're talking past each other. I don't understand your objection yet, and I want to so I can design (or redesign) to meet it. When I talk about rules that use architecture symbols to suppress things like bus types I have in mind things like this: unless X86 suppress dependent MCA EISA unless MIPS32 suppress dependent TC unless (PCI and (X86 or SUPERH)) suppress pci_access unless (ISA or PCI) suppress dependent IDE unless PCI suppress dependent USB HOTPLUG_PCI unless (X86 or ALPHA or MIPS32 or PPC) suppress usb unless (X86 and PCI and EXPERIMENTAL) or PPC or ARM or SPARC suppress dependent IEEE1394 unless (M68K or ALL_PPC) suppress MACINTOSH_DRIVERS unless SPARC suppress dependent FC4 unless ARCH_S390==n suppress buses It seems to me *extremely* unlikely that a typical patch from a PPC maintainer would mess with any of these! They're rules that are likely to be written once at the time a new port is added to the tree and seldom or ever changed afterwards. Thus I really don't think you have to worry about spurious spikes in your diffstat. The root rules.cml file will not change very often -- I know this is true, because I can look at the RCS history since I broke it out in response to your request at the Kernel Summit and *see* that changes have been few and sparse. In contrast, if it starts talking about Documentation/Configure.help and the main config file, I start worrying. Rightly so in the latter case. Configure.help patches shouldn't worry you, I don't think. It's not like they can actually break anything. For example, that MATHEMU thing is just ugly. It was perfectly fine in the per-architecture version, now it suddenly has magic dependencies just because different architectures call it different things, and different architectures have different rules on when it's needed. It sounds to me like you're agreeing that it *shouldn't* be called different things, and thus with my goal of cleaning this mess up the rest of the way. Yes? No? Guidance, please. I am, as ever, willing to meet your concerns. But I have to understand clearly what they are in order to do that. -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a ...The Bill of Rights is a literal and absolute document. The First Amendment doesn't say you have a right to speak out unless the government has a 'compelling interest' in censoring the Internet. The Second Amendment doesn't say you have the right to keep and bear arms until some madman plants a bomb. The Fourth Amendment doesn't say you have the right to be secure from search and seizure unless some FBI agent thinks you fit the profile of a terrorist. The government has no right to interfere with any of these freedoms under any circumstances. -- Harry Browne, 1996 USA presidential candidate, Libertarian Party ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Re: State of the new config build system
Linus Torvalds [EMAIL PROTECTED]: Eric, this is the _wrong_approach_. I want /local/ files, not global ones. I hear you. There are some problems with that, however. First: where should the prompt-string definitions for capability symbols that occur in multiple port trees live? (This is an important question. Right now, most options are low-level and platform-specific, which makes it easy to decide what directory their symbol declaration(s) should live in. But that's not good; there are lots of excellent reasons we want there to be *more* cross-platform capability symbols rather than fewer. So the percentage of roving symbols without an obvious home is likely to go up over time.) Second: Forward references, and references across the tree, mean that there is a class of symbols that have theoretically natural home directories but which would have to be declared elsewhere in order to be defined at the point of first reference. (A potential solution to this would be to improve the CML2 compiler's handling of forward references.) Third: I could hack my installer to break Configure.help up into a bunch of little component CML files distributed through the tree... but Configure.help doesn't currently contain any markup that says where to direct each entry to. (The logical time to split up symbols.cml would be immediately after CML2 goes into the tree, because at that point Configure.help won't be an issue any more.) Fourth: There's still the localization issue. If it's your ukase that this is not an important problem, then I'll accept that -- but I haven't heard you say that yet, so I'm not sure you've considered it enough. So, I can and will put this in the transition plan if that's what you direct. But you need to be aware that it's not a snap-of-the-fingers change, and not something best done before CML1 goes away. -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a As to the species of exercise, I advise the gun. While this gives [only] moderate exercise to the body, it gives boldness, enterprise, and independence to the mind. Games played with the ball and others of that nature, are too violent for the body and stamp no character on the mind. Let your gun, therefore, be the constant companion to your walks. -- Thomas Jefferson, writing to his teenaged nephew. ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: State of the new config build system
Alan Cox [EMAIL PROTECTED]: I'd be happy to take another swing at this problem once the kbuild-2.5/CML2 transition is done. But I don't think we should let it block us from having the good results we can get from that change. It would certainly fit nicely with the existing metadata. We already rip out code comments via kernel-doc, and extending it to rip out - Help text - Web site - Version information - Man page for the driver - Module options etc, shouldn't be too challenging. Ok so kernel-doc is in perl and ugly perl but if someone hates it enough to rewrite it in python thats a win too 8) I've been thinking about doing that very thing anyway. Part of my master plan to reduce the tree's external dependencies. -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a I do not find in orthodox Christianity one redeeming feature. -- Thomas Jefferson ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] CML2-1.9.15
The latest version is always available at http://www.tuxedo.org/~esr/cml2/ Release 1.9.15: Thu Dec 27 04:44:31 EST 2001 * Alternate tree-widget-based X interface by W. Chang [EMAIL PROTECTED] introduced. * Corrected a CML2 compiler bug in `suppress depends' handling, thanks to Rob Landley. We have an entire new front end in this release, code based on a tree width that shows a nice folder view of the configuration menus. Install and try out `make treeconfig' to see it. -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a Strict gun laws are about as effective as strict drug laws...It pains me to say this, but the NRA seems to be right: The cities and states that have the toughest gun laws have the most murder and mayhem. -- Mike Royko, Chicago Tribune ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: State of the new config build system
Dave Jones [EMAIL PROTECTED]: Maybe keep them both in the tree until this issue is worked out ? That way those who want to play with kbuild can do so, and those who build a few dozen kernels a day don't have to twiddle thumbs. That is such an unutterably horrible concept that the very tentacles of Cthulhu himself must twitch in dread at the thought. The last thing anyone sane wants to do is have to maintain two parallel build systems at the same time. -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a You know why there's a Second Amendment? In case the government fails to follow the first one. -- Rush Limbaugh, in a moment of unaccustomed profundity 17 Aug 1993 ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Re: State of the new config build system
Tom Rini [EMAIL PROTECTED]: I think Keith wanted a very small time window tho (~24 hrs, barring big supprises). But if we're going to be worried about the build time, kbuild-2.5 and cml2 aren't co-dependant, yes? I know kbuild-2.5 works w/o cml2, and last I tried (ages ago admitedly) cml2 didn't need kbuild-2.5. That's right. CML2 and kbuild-2.5 do not require each other So we could, in theory dump cml1 quickly but leave the old Makefiles for a bit longer. Or if Keith thinks he can start on the speed problems soon, just plod along for a few releases. :) As Keith has pointed out, old kbuild achieves its speed by being broken. That's an argument for plod along, IMHO. -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a (Those) who are trying to read the Second Amendment out of the Constitution by claiming it's not an individual right (are) courting disaster by encouraging others to use the same means to eliminate portions of the Constitution they don't like. -- Alan Dershowitz, Harvard Law School ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] CML2-1.9.16 is available
The latest version is always available at http://www.tuxedo.org/~esr/cml2/ Release 1.9.16: Fri Dec 28 01:02:17 EST 2001 * Rulebase and help sync with 2.4.18-pre1/2.5.2-pre3. * More logic fixes by Richard Todd. * Split out ISA_CARDS from ISA in the rulebase. There is now an automatic regression test for the constraint engine; see the file torture.test in the distribution. Richard Todd has been doing excellent work fixing various edge cases where the engine does fluky things and nailing them down in regression tests. -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a To make inexpensive guns impossible to get is to say that you're putting a money test on getting a gun. It's racism in its worst form. -- Roy Innis, president of the Congress of Racial Equality (CORE), 1988 ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] CML2-1.9.14 is available
Release 1.9.14: Wed Dec 26 22:10:25 EST 2001 * Rulebase and help sync with 2.4.18-pre1/2.5.2-pre2. * Fix a bug in handling of the private bit. A normal point release, issued mainly to update the rulebase. -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects. -- Robert A. Heinlein, Time Enough for Love ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] CML2 1-9-13 is available
Release 1.9.13: Mon Dec 24 13:36:24 EST 2001 * SuperH rulebase corrections from Niibe Yutaka. * Corrections for Richard Todd's logic bugs. The bug queue is empty. However, Richard Todd and I will be testing more weird theorem-prover cases in the near future looking for problems, and might well find some. -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a [President Clinton] boasts about 186,000 people denied firearms under the Brady Law rules. The Brady Law has been in force for three years. In that time, they have prosecuted seven people and put three of them in prison. You know, the President has entertained more felons than that at fundraising coffees in the White House, for Pete's sake. -- Charlton Heston, FOX News Sunday, 18 May 1997 ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] CML 1.9.12 is available
Release 1.9.12: Sat Dec 22 13:35:14 EST 2001 * Rulebase and help sync with 2.4.17-rc2/2.5.2-pre1. * Corrected a typo in kxref.py that caused portability problems. Ordinary point release for beta testers. I'm still working on Richard Todd's dependency bugs, and they're still unlikely to be a problem in ordinary cases. -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a A ``decay in the social contract'' is detectable; there is a growing feeling, particularly among middle-income taxpayers, that they are not getting back, from society and government, their money's worth for taxes paid. The tendency is for taxpayers to try to take more control of their finances...-- IRS Strategic Plan, (May 1984) ___ 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
Steven Cole [EMAIL PROTECTED]: 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 Aaarrgghh. I typoed. Apply this patch: --- kxref.py2001/12/20 08:56:58 1.51 +++ kxref.py2001/12/20 18:56:55 @@ -137,7 +137,7 @@ def makexref(tree): Generate a cross-reference dictionary for the given source tree. -global typefind, choicere, configre, definre, mycml1types +global typefind, choicere, configre, definere, mycml1types typefind = re.compile(r(?!define_)(bool|tristate|int|hex|string)\s+'.*'\s+CONFIG_(\w+)) choicere = re.compile(r^\s*choice) configre = re.compile(rulebase.prefix + r(\w*)) That should make it run under all 2.x versions. -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a Government is not reason, it is not eloquence, it is force; like fire, a troublesome servant and a fearful master. Never for a moment should it be left to irresponsible action. -- George Washington, in a speech of January 7, 1790 ___ 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
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. -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a ...Virtually never are murderers the ordinary, law-abiding people against whom gun bans are aimed. Almost without exception, murderers are extreme aberrants with lifelong histories of crime, substance abuse, psychopathology, mental retardation and/or irrational violence against those around them, as well as other hazardous behavior, e.g., automobile and gun accidents. -- Don B. Kates, writing on statistical patterns in gun crime ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] CML2 1.9.11 is available
Release 1.9.11: Wed Dec 19 23:57:21 EST 2001 * Added a ruleset-debugging mode to cmlconfigure.py. * Add 'like' keyword so help entries can be re-used by reference. * Fix some scoping problems in kxref.py that confused pre-2.2 Pythons. I haven't solved Richard Todd's bugs in the logic engine yet =-- fortunately they don't show up in ordinary use. I expect to nail these shortly. -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a Americans have the will to resist because you have weapons. If you don't have a gun, freedom of speech has no power. -- Yoshimi Ishikawa, Japanese author, in the LA Times 15 Oct 1992 ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Re: CML2 1.9.9 ia64
Greg Banks [EMAIL PROTECTED]: Would it be possible to add a keyword to the `symbols' statement which causes a symbol to use another (previously declared?) symbol's helptext? This would be a relatively simple change and would ease Keith's help text maintenance burden. I've been thinking about implementing this for other reasons. I'll work on it. -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a The Constitution is not neutral. It was designed to take the government off the backs of the people. -- Justice William O. Douglas ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: CML2 1.9.9 ia64
Keith Owens [EMAIL PROTECTED]: Testing cml2 1.9.9, kbuild 2.5, 2.4.16-ia64-011214. config.out, line 267: bad token `SCSI_DEBUG_QUEUES' while expecting symbol. Stock 2.4.16 defines SCSI_DEBUG_QUEUES, it is used in drivers/scsi/scsi_merge.c. SCSI_DEBUG_QUEUES should be in cml2. It has dropped out of the 2.4.17-pre series, which is what I'm tracking. config.out, line 313: bad token `SCSI_QLOGIC_QLA2100' while expecting symbol. New option in the ia64 patch. config.out, line 522: bad token `AGP_I460' while expecting symbol. Not sure if that is a new option or an old one come back to haunt us. The ia64 patch reinstates the drm 4.0 code that Linus threw out, drm 4.1 does not completely work on ia64 yet. I don't think I've ever seen either of those. config.out, line 666: bad token `EFI_PARTITION' while expecting symbol. New option in the ia64 patch. config.out, line 667: bad token `DEVFS_GUID' while expecting symbol. New option in the ia64 patch. What is the best way in CML2 of handling arch specific patches that add options? Umm...to have the submitter include a patch for the rulebase? I don't know an obviously better way. File load violated these constraints: (SMP implies (X86 or (PPC or (ALPHA_SABLE or (ALPHA_RAWHIDE or (ALPHA_DP264 or (ALPHA_WILDFIRE or (ALPHA_TITAN or (ALPHA_GENERIC or (SPARC32 or (MIPS64 or ARCH_S390))) IA64 is missing from the SMP list,easily fixed. Done. I need to think about your feature request. I'll respond in a separate posting. -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a Today, we need a nation of Minutemen, citizens who are not only prepared to take arms, but citizens who regard the preservation of freedom as the basic purpose of their daily life and who are willing to consciously work and sacrifice for that freedom.-- John F. Kennedy ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: CML2 1.9.9 ia64
Keith Owens [EMAIL PROTECTED]: Only one of the menus will be visible, but the rule compiler does not know that. This is the problem for which the solution was to change choice to dynamically pick a default. I don't like that solution for two reasons :- (1) The overall help text for the choice is fixed, I cannot provide different hints for each architecture. Which means I cannot tell sparc users about milo, x86 users about lilo or grub etc. (2) It leads to horrible expressions like unless (X86 or (ALPHA or (SPARC32 or (SPARC64 or (MIPS32 or (MIPS64 or (PPC or (M68K or (ARM or (SUPERH or (IA64 or (PARISC or (S390 or (S390X or CRIS)) suppress VMLINUZ That is worst case, but all it takes is one arch that does not support a particular boot format and we need expressions like that. The expression must be repeated for each boot format that is not universally available. Every new architecture has to find and change these rules. You can see why I wanted per architecture choices instead of one big choice with conditions. Is there any way of getting there? One possibility is to allow symbols to occur more than once as long as they are guarded, including being on menus that are completely suppressed. The rule back end refuses any input that makes the symbol visible in two places at once. IOW, delay the check for duplicate use of a symbol until the visibility data is known. Duplicate definition is always an error, duplicate use is only an error if the symbol is visible more than once. OK. That might be a nice idea, but the symbols-occur-in-one-place-only assumption is wired *deep* into the code for me to want to mess with it when it's not at all hard to write rules with equivalent properties. The right answer looks like this: - symbols kernel_format_x86 'The format used for the installed kernel' text All kernel builds create vmlinux as an ELF object. vmlinux may not be suitable for loading, either because the bootloader cannot handle ELF or the object is too large. This option selects the format for the installed kernel. If unsure, use bzImage. . unless X86 suppress kernel_format_x86 private VMLINUX_X86 VMLINUZ_X86 BZIMAGE_X86 ZIMAGE_X86 choices kernel_format_x86 # The format that the kernel is to be compiled in VMLINUX_X86 VMLINUZ_X86 BZIMAGE_X86 ZIMAGE_X86 default BZIMAGE_X86 menu installation kernel_format_x86 === arch/ia64/boot/rules-2.5.cml. symbols kernel_format_ia64 'The format used for the installed kernel' text All kernel builds create vmlinux as an ELF object. vmlinux may not be suitable for loading, either because the bootloader cannot handle ELF or the object is too large. This option selects the format for the installed kernel. If unsure, use vmlinuz. . unless IA64 suppress kernel_format_ia64 private VMLINUX_IA64 VMLINUZ_IA64 choices kernel_format_ia64 # The format that the kernel is to be compiled in VMLINUX_IA64 VMLINUZ_IA64 default VMLINUZ_IA64 menu installation kernel_format_ia64 # Here's where we pull everything together into # architecture-independent symbols... derive VMLINUX from VMLINUX_X86 or VMLINUX_IA64 derive VMLINUZ from VMLINUZ_Z86 or VMLINUZ_IA64 derive BZIMAGE from BZIMAGE_X86 derive ZIMAGE from ZIMAGE_X86 - This way, you get to have your architecture-dependent help symbols and your across-architecture build symbols both, *and* you make the relationships explicit. The `private' declaration prevents your internal symbols from being written to the config. -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a Militias, when properly formed, are in fact the people themselves and include all men capable of bearing arms. [...] To preserve liberty it is essential that the whole body of the people always possess arms and be taught alike, especially when young, how to use them. -- Senator Richard Henry Lee, 1788, on militia in the 2nd Amendment ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Configure.help has complete coverage for 2.4 and 2.5.
For only the second time in recorded history, the master Configure.help file now has help entries corresponding to *all* configuration symbols in live use in the kernel tree (both 2.4 and 2.5). It is available for your downloading pleasure at: http://tuxedo.org/~esr/cml2/Configure.help.gz Fossil entries in this version have been garbage-collected out (I'm keeping them in a dead-entries file in case any of them becomes interesting again.) Entries for which the question symbol has merely been commented out in CML1 have been retained. I had to write over 600 of the entries in this version myself, including the last six. Please don't put me through that again -- when you add a config option, *include a Configure.help entry in your patch*. Not documenting how and why to configure your option is both sloppy and antisocial. I beseech the current Elder Gods of the kernel to reject future patches that neglect this step. Thanks to everyone who responded well to my nagging by sending in entries. -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a Strict gun laws are about as effective as strict drug laws...It pains me to say this, but the NRA seems to be right: The cities and states that have the toughest gun laws have the most murder and mayhem. -- Mike Royko, Chicago Tribune ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] CML2 1.9.7 is available
Keith Owens [EMAIL PROTECTED]: Dangling symlink kernel-tree/scripts/tree.py breaks the CML2 install, rm kernel-tree/scripts/tree.py first. Fixed. There are still discrepancies between the output produced by different forms of make *config. I am also seeing spurious deduction messages which may be related or may be a separate problem. Separate problem. Why are those deduction messages appearing in menuconfig? I just did make oldconfig, the config should be stable. I did not change anything in menuconfig, just saved it. The deduction messages are happening because the side-effect forcing logic fires whenever a symbol is set. It has no way of knowing whether or not the forced symbol will occur later in the config being read. This Why is the output after menuconfig WITH NO CHANGES different from the oldconfig that went into menuconfig? I think it's because of the different timing of menu visits (forcing computation of choice-menu defaults at different times). I'm going to run some experiments to see if I can pin this down. -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a The state calls its own violence `law', but that of the individual `crime' -- Max Stirner ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] CML2 1.9.7 is available
Keith Owens [EMAIL PROTECTED]: OUCH! The output from make menuconfig has significantly more options than make oldconfig when given exactly the same input. I thought one of the selling points for CML2 was different front ends but with identical back end processing. I don't like the way that the resulting config varies when fed to different front ends. Not a big deal -- all the produced config.outs are logically equivalent. Your differences all consist of symbols saved out as n in one version and not saved at all in the other. It *would* be serious cause for alarm if that were not the case. The simplification in the saveability-predicate logic I just did for 1.9.8 made may help solve this problem. -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a .. a government and its agents are under no general duty to provide public services, such as police protection, to any particular individual citizen... -- Warren v. District of Columbia, 444 A.2d 1 (D.C. App.181) ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] CML2 1.9.9 is available
The latest version is always available at http://www.tuxedo.org/~esr/cml2/ Release 1.9.9: Thu Dec 13 18:36:26 EST 2001 * Minor cleanups by Richard Todd. * Passed Keith Owens's regression tests against CML1 make oldconfig. Bug queue is empty. The code has passed scrutiny and hands-on use by the rest of the kbuild team. There's a known rulebase glitch near extra-device handling of SCSI disks which is not critical and should be a one-line fix by somebody who knows what is actually going on there. Things have come together nicely: (a) the code is ready and tested, (b) the rulebase needs only trivial cleanups, and (c) the Configure.help file is down to only 14 missing entries, with 6 of the remaining promised any time now. It looks like we'll actually be ready to do a major-number release after 1.9.9. -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a America is at that awkward stage. It's too late to work within the system, but too early to shoot the bastards. -- Claire Wolfe ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: CML2 1.9.6 is available
Lars Brinkhoff [EMAIL PROTECTED]: Eric S. Raymond [EMAIL PROTECTED] writes: Right now I'm testing Jan Harknes's CML1 backport patch. It's the second time I see this CML1 backport mentioned. You sure you don't mean the Python1 backport? Sorry, that is what I meant. -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a Those who make peaceful revolution impossible will make violent revolution inevitable. -- John F. Kennedy ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] CML2 1.9.7 is available
Keith Owens [EMAIL PROTECTED]: IMHO the only correct method is to write out only the visible symbols. The current logic looks like this: 1. If the symbol has been explicitly set, write it out. 2. Otherwise, if the symbol's visibility predicate is all frozen symbols and is n, suppress it. 3. Otherwise, if an ancestor symbol is n, suppress it. 4. Otherwise write it out. Am I being too complicated here? Also I suspect that part of the CML2 problem is inconsistent state about which symbols are visible or not, caused by the slightly different constraints of the front ends. If that is the case, the fix is obvious. The front ends all use the same rulebase, so they're deducing from the same constraints. And they all use the same is_visible() predicate. Once an acceptable config has been entered and has passed all the rules, delete all visibility state from the config and recalculate the visbility state of each symbol from scratch. That is probably the only way to guarantee identical output irrespective of front end variations. There is no visibility state to delete. Visibility is recomputed every time, so this is the way it's done now. -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a I hold it, that a little rebellion, now and then, is a good thing, and as necessary in the political world as storms in the physical. -- Thomas Jefferson, Letter to James Madison, January 30, 1787 ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] CML2 1.9.7 is available
Keith Owens [EMAIL PROTECTED]: On Wed, 12 Dec 2001 11:29:47 -0500, Eric S. Raymond [EMAIL PROTECTED] wrote: Keith Owens [EMAIL PROTECTED]: IMHO the only correct method is to write out only the visible symbols. The current logic looks like this: 1. If the symbol has been explicitly set, write it out. 2. Otherwise, if the symbol's visibility predicate is all frozen symbols and is n, suppress it. 3. Otherwise, if an ancestor symbol is n, suppress it. 4. Otherwise write it out. Am I being too complicated here? Probably. CML1 just does 3+4. 1 propagates symbols that were set at some time in the past, they get written out even when set to n. I can drop test 1. But if I do that, and user sets a symbol he found via a search command, and that symbol doesn't happen to be normally visible, and then saves, he's not going to get the result he expects. I can't drop test 2. This is the test that prevents saving SPARC symbols when X86 is frozen on. Typically, architecture-dependent choices are not descendents of the arch symbol, they merely have it in their visibility expressions. Maybe I ought to just collapse 3 and 4 into write it out if it's visible. I'll perform some experiments. Also I suspect that part of the CML2 problem is inconsistent state about which symbols are visible or not, caused by the slightly different constraints of the front ends. If that is the case, the fix is obvious. The front ends all use the same rulebase, so they're deducing from the same constraints. And they all use the same is_visible() predicate. So why do different front ends produce different output when fed identical input? I don't know yet. The only opening I can see for producing this kind of variation is the funky way defaults in choice menus are determined. Long ago I computed them at rulebase compile time, but this kept running me into constraint errors. Also, there are issues about the right thing when the choice menu's compiled default happens to have its visibility predicate evaluate to n at runtime... So choice defaults are not actually computed until the time the menu is first visited by the user. What differs beween front ends is the timing of first visit. In ttyconfig you don't visit a menu until you touch one of the symbols inside it. In menuconfig and xconfig you also visit a menu the first time its parent menu gets thrown on the display -- because a submenu is only supposed to be visible if it has visible symbols inside it. I'm going to have to stare at this code for a while. -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a The right to buy weapons is the right to be free. -- A.E. Van Vogt, The Weapon Shops Of Isher, ASF December 1942 ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] kbuild-2.5 and the apha
Keith Owens [EMAIL PROTECTED]: On Tue, 11 Dec 2001 19:33:25 -0500, Eric S. Raymond [EMAIL PROTECTED] wrote: Keith Owens [EMAIL PROTECTED]: Is there a way we could split the help entries into arch specific entries ? like using config variables CONFIG_INSTALL_$ARCH_VMLINUX or something ? AFAICT, not in CML1. The CML1 help text is under the first entry on the choice list. In CML2 each choice entry has its own help text. Not quite yet. CML2 still uses the CML1 convention. That will change after cutover. It already works for me using cml2 1.9.6. The help text for the menu item is one entry, the individual choices have separate text. It uses the CML1 convrntion as a fallback. -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a Every Communist must grasp the truth, 'Political power grows out of the barrel of a gun.' -- Mao Tse-tung, 1938, inadvertently endorsing the Second Amendment. ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: CML2 1.9.6 is available
Keith Owens [EMAIL PROTECTED]: One niggle, some strings for kuild 2.5 are longer than 30 characters, cml2 restricts the string length in make menuconfig. Only menuconfig has this restriction, not oldconfig nor xconfig. Can the limit be removed, or at least changed to $ROWS-n which would adjust to screen size? The only place I see a limit of 30 is in the query_popup function used for querying for things like search strings, symbol names in the go-to command, etc. in menuconfig. The answer is: maybe. The underlying problem here is that the prompt string and the string editing area both eat screen width. 30 is about the largest limit that doesn't blow up the configurator when combined with the longest prompt strings. -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a Everything you know is wrong. But some of it is a useful first approximation. ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: CML2 1.9.6 is available
Keith Owens [EMAIL PROTECTED]: This works for me. --- cml2-1.9.6/cmlconfigure.pySun Dec 9 19:27:31 2001 +++ 2.4.16-kbuild-2.5/scripts/cmlconfigure.py Wed Dec 12 17:23:01 2001 @@ -1009,7 +1009,7 @@ def query_popup(self, prompt, initval=None): Pop up a window to accept a string. -maxsymwidth = 30 # Constant +maxsymwidth = self.columns - len(prompt) - 2 if initval and len(initval) maxsymwidth: self.help_popup(PRESSANY, (lang[TOOLONG],), beep=1) return initval Warning, that is my first bit of Python code (Oh no, now I'm contaminated too :-). And a very nice bit it is too :-). I actually ended up making a similar change shortly after I wrote you. Right now I'm testing Jan Harknes's CML1 backport patch. -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a I do not find in orthodox Christianity one redeeming feature. -- Thomas Jefferson ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: CML2 1.9.6 is available
Richard Todd [EMAIL PROTECTED]: I already found an improvement for the previous patch, so I made a new one against plain cml2-1.9.6. This one works slightly better for problem (2). It makes sure that anything it might rebind the ancestor to is either a bool or trit. I'm impressed. It's a good fix. You had to have gotten pretty deep into the core logic and data structures to spot that. Comments? Were they fairly clear? Is there something I could usefully do to improve the internal documentation? -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a The power to tax involves the power to destroy;...the power to destroy may defeat and render useless the power to create -- Chief Justice John Marshall, 1819. ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] CML2 1.9.6 is available
Release 1.9.6: Sun Dec 9 03:23:55 EST 2001 * Rulebase and help sync with 2.4.17-pre6/2.5.1-pre8. * Corrected casting in default computation. The bug queue is empty. -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a The right of the citizens to keep and bear arms has justly been considered as the palladium of the liberties of a republic; since it offers a strong moral check against usurpation and arbitrary power of rulers; and will generally, even if these are successful in the first instance, enable the people to resist and triumph over them. -- Supreme Court Justice Joseph Story of the John Marshall Court ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] CML 1.9.5 is available.
Release 1.9.5: Sat Dec 8 02:47:21 EST 2001 * Rulebase and help sync with 2.4.17-pre6/2.5.1-pre7. * Some edge cases in casting of default expressions are handled better. * It is documented that suppressing a symbol suppresses all its dependents. * Correction for Keith Owens's visibility bug. Keith Owens has an it would be nice bug report pending related to suppression of symbols in the config output. The queue is otherwise empty. I'm also looking at the CML1 backport patch. -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a Morality is always the product of terror; its chains and strait-waistcoats are fashioned by those who dare not trust others, because they dare not trust themselves, to walk in liberty. -- Aldous Huxley ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] kao.cml visibility
I'm still analyzing the behavior of the rulesfile you sent me. I'm
not yet certain whether what you have showed me pilot error, a bug, or
a design flaw. This in itself means that I have to clean up some
relevant parts of the language description. I'll work on that today.
In the meantime, here is the *rigt* way to get the effect you want.
---
prefix CONFIG_# Stripped at read time, prepended at save time
start main # Start with the menu named 'main'
symbols
VMLINUX 'vmlinux' text
This is the raw format that is produced by the kernel build. It is
required to use any of the various source debugging tools on the kernel
itself and is the only bootable format on some architectures. It is
generally too large to be used otherwise.
.
INSTALL_VMLINUX 'Install vmlinux for debugging' text
If you are debugging a kernel, you usually need vmlinux as well as the
bootable kernel. Unless you plan to debug the kernel, reply N.
.
INSTALL_VMLINUX_NAME 'Where to install vmlinux' text
If you are debugging a kernel, you usually need vmlinux as well as the
bootable kernel. For debugging, the recommended value is
/lib/modules/KERNELRELEASE/vmlinux. The path will be prefixed by
CONFIG_INSTALL_PREFIX.
.
menus main dummy
menu main
VMLINUX {INSTALL_VMLINUX {INSTALL_VMLINUX_NAME$}}
default INSTALL_VMLINUX_NAME from /boot/vmlinux
---
I think that clears out your bug queue, yes?
--
a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a
A nation or civilization that continues to produce soft-minded men
purchases its own spiritual death on an installment plan.
--Martin Luther King, Jr.
___
kbuild-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: Converting the 2.5 kernel to kbuild 2.5
Keith Owens [EMAIL PROTECTED]: It turns out that I had CML2 support working last week, every problem I hit has been traced to a CML2 bug, not kbuild 2.5. I am ready to send kbuild 2.5 to Linus, initially without CML2 support. Eric, it is trivial to activate the CML2 support in kbuild once the CML2 bug list is empty. I'm on it. I'd have fixed your bugs before now but I just came off a busy three-day road trip. -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a No kingdom can be secured otherwise than by arming the people. The possession of arms is the distinction between a freeman and a slave. -- Political Disquisitions, a British republican tract of 1774-1775 ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Re: your mail
Linus Torvalds [EMAIL PROTECTED]: Linus, the time has come to convert the 2.5 kernel to kbuild 2.5. We're getting the block IO layer in shape first, the time has not come for _anything_ else before that. Right, that is more important. We'll be ready when you're done. -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a The kind of charity you can force out of people nourishes about as much as the kind of love you can buy --- and spreads even nastier diseases. ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5
Rob Landley [EMAIL PROTECTED]: P.S. Can we seperate add new subsystem y prime and remove old subsystem y. LIke the new and old SCSI error handling, which have been in the tree in parallel for some time? Did I hear Eric ever suggest removing the old configurator for 2.4? Anybody? The whole point of putting the new configurator in would be to be able to drop the old one out. But that would be strictly Marcelo's call. It would be up to him to decide whether the tradeoff were worth it. -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a Everything you know is wrong. But some of it is a useful first approximation. ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: Switching CML2 back to python1.5x min.
Tom Rini [EMAIL PROTECTED]: Getting ncurses and python1.5.x to work is painful, or ncurses + (python 1.5.x || python 2.x) is painful? All of the above. Besides, the whining about 2.0 is just a displacement. If I fix that, they'll just bitch about sometging else. -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a Sometimes it is said that man cannot be trusted with the government of himself. Can he, then, be trusted with the government of others? -- Thomas Jefferson, in his 1801 inaugural address ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: Converting the 2.5 kernel to kbuild 2.5
Cameron Simpson [EMAIL PROTECTED]: ESR, is it practical to have CML2 transcribe a CML1 config file? No, alas. -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a Government should be weak, amateurish and ridiculous. At present, it fulfills only a third of the role. -- Edward Abbey ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5
Greg Banks [EMAIL PROTECTED]: It seems my main contribution has been to provide Eric with incentive to clarify his language spec and speed up his parser. Stimulus for which I have been deeply grateful. -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a ..every Man has a Property in his own Person. This no Body has any Right to but himself. The Labour of his Body, and the Work of his Hands, we may say, are properly his. The great and chief end therefore, of Mens uniting into Commonwealths, and putting themselves under Government, is the Preservation of their Property. -- John Locke, A Treatise Concerning Civil Government ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5
Christoph Hellwig [EMAIL PROTECTED]: On Mon, Dec 03, 2001 at 12:06:12PM +1100, Keith Owens wrote: The CML1 to CML2 conversion comes later, either in 2.5.3 or 2.5.4. Is the CML2 merge actually agreed on? Yes, unless Linus has changed his mind since March. Which would be his privilege, of course -- but since the CML1 maintainers are unanimous that CML1 is too kludgy to live and Linus knows that, it seems unlikely. -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a All governments are more or less combinations against the people. . .and as rulers have no more virtue than the ruled. . . the power of government can only be kept within its constituted bounds by the display of a power equal to itself, the collected sentiment of the people. -- Benjamin Franklin Bache, in a Phildelphia Aurora editorial 1794 ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5
Giacomo Catenazzi [EMAIL PROTECTED]: I don't think esr changed non problematic rules, but one: all rules without help become automatically dependent to CONFIG_EXPERIMENTAL. I don't like it, but I understand why he makes this decision. No, it's CONFIG_EXPERT. And this change is not wired in. Comment out this declaration in the top-level rulesfile: condition nohelp on EXPERT and it reverts to old behavior. -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a The conclusion is thus inescapable that the history, concept, and wording of the second amendment to the Constitution of the United States, as well as its interpretation by every major commentator and court in the first half-century after its ratification, indicates that what is protected is an individual right of a private citizen to own and carry firearms in a peaceful manner. -- Report of the Subcommittee On The Constitution of the Committee On The Judiciary, United States Senate, 97th Congress, second session (February, 1982), SuDoc# Y4.J 89/2: Ar 5/5 ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5
David Woodhouse [EMAIL PROTECTED]: [EMAIL PROTECTED] said: I don't think esr changed non problematic rules, but one: all rules without help become automatically dependent to CONFIG_EXPERIMENTAL. I don't like it, but I understand why he makes this decision. That is precisely the kind of bogus change which should _not_ be done in such an underhand way. Underhanded? Hardly. It was right there, with explanation, in one of the release announcements I've been posting. -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a As war and government prove, insanity is the most contagious of diseases. -- Edward Abbey ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: Switching CML2 back to python1.5x min.
Tom Rini [EMAIL PROTECTED]: I think one of the large arguments against CML2 right now is that it needs Python 2.0+ to work, instead of 1.5.x. IIRC, back in the begining, 1.5.x was used but then switched to 2.0 because it allowed for a lot of code to be dropped. Eric, would it be not-too-painful to either go back to 1.5.x minimum, or could we do a runtime check for 2.x and either do the extra things for 1.5 or not, depending (not sure if that's worth the bother). This would allow a lot more distros already out there to just work. There's a problem. It's called ncurses. This might be doable but it would be very, very painful. -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a Freedom, morality, and the human dignity of the individual consists precisely in this; that he does good not because he is forced to do so, but because he freely conceives it, wants it, and loves it. -- Mikhail Bakunin ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5
Tom Rini [EMAIL PROTECTED]: Maybe for you. For me it *is* an issue. I don't like more and more dependencies for the kernel. I mean, if I can drop kbuild and keep on building the kernel with the old good 'make config' I won't worry, but otherwise I don't think that kernel building depends on something like Python. One of the things that I _think_ is happening is that lots of other scripts/ files are being redone, and thus removing them from the list, so in effect we're trading out one or two for just Python. That is my intention. The right tools for the right job. C is good for the kernel. Python is good at manipulating strings. *Perl* is good at strings. Python is good at actual data structures :-). -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a The people of the various provinces are strictly forbidden to have in their possession any swords, short swords, bows, spears, firearms, or other types of arms. The possession of unnecessary implements makes difficult the collection of taxes and dues and tends to foment uprisings. -- Toyotomi Hideyoshi, dictator of Japan, August 1588 ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5
David Weinehall [EMAIL PROTECTED]: Yeah, let's lose the dependencies on perl, make, awk, sed, ld, ar, nm, strip, objcopy, objdump, depmod, grep, xargs, find, gzip, wish, tcl/tk and possibly others. That'd surely shave a lot of diskspace off my buildsystem. It's not like I use any of them for anything else... I'm going to remove a few of these. -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a 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) ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Dead symbols
Michael Elizabeth Chastain [EMAIL PROTECTED]: Linux is an OS by hackers, for hackers, and it's part of our culture to share information. If an option is a historical relic and connected to nothing, say so. If an option is very new and is not used yet because someone's tree isn't merged at this time, say so. If an option has a typo in its name and is about to be renamed -- say so. Document the system with truth and openness, and use tools to check that the set of options is current. I agree with this design philosophy. In this case, however, since these configuration options are thoroughly dead and subsumed by a boot-time option, it appears the right thing to do is just to remove them. What I have done is remove those two options in CML2. Here is a patch that will remove them from the 2.5.1-pre and 2.4.17-pre trees: --- arch/cris/config.in 2001/12/03 17:34:09 1.1 +++ arch/cris/config.in 2001/12/03 17:34:28 @@ -246,8 +246,4 @@ comment 'Kernel hacking' #bool 'Debug kmalloc/kfree' CONFIG_DEBUG_MALLOC -bool 'Kernel profiling support' CONFIG_PROFILE -if [ $CONFIG_PROFILE = y ]; then - int ' Profile shift count' CONFIG_PROFILE_SHIFT 2 -fi endmenu Linus and Marcelo, please apply. -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a The spirit of resistance to government is so valuable on certain occasions, that I wish it always to be kept alive. It will often be exercised when wrong, but better so than not to be exercised at all. I like a little rebellion now and then. -- Thomas Jefferson, letter to Abigail Adams, 1787 ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: Missing Configure,help entries need filling in
Urban Widmark [EMAIL PROTECTED]: VIA_RHINE_MMIO This bit was included in the original patch. Do you want it as a patch for 2.4 also or do you merge by-hand anyway? This was fine, thanks. -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a Of all tyrannies, a tyranny exercised for the good of its victims may be the most oppressive. It may be better to live under robber barons than under omnipotent moral busybodies. The robber baron's cruelty may sometimes sleep, his cupidity may at some point be satiated; but those who torment us for our own good will torment us without end, for they do so with the approval of their consciences. -- C. S. Lewis ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] CML2 1.9.4 is available
Release 1.9.4: Sun Dec 2 14:12:18 EST 2001 * Rulebase and help sync with 2.4.17-pre2/2.5.1-pre5. * Symbols are now unsaveable when an ancestor is n (that is, the ancestor may now be unfrozen). Problems reported by Keith Owens and Dave Relson have been fixed. Greg Banks's feature suggestion for handling kernel format variations across architectures has been implemented. The bug queue is empty. -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a The Constitution is not neutral. It was designed to take the government off the backs of the people. -- Justice William O. Douglas ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Dead symbols
The following symbols occur only in CML1 configuration files and not .c or .h files or makefiles. Can amy of these be eliminated entirely? This would help me cut the missing-help-entries list. ARCH_CLEP7312: arch/arm/config.in ARCH_EDB7211: arch/arm/config.in EP72XX_ROM_BOOT: arch/arm/config.in EVB_PCI1: arch/mips/config.in FORWARD_KEYBOARD: arch/mips/config.in GSC_DINO: arch/parisc/config.in IA64_SGI_SN_DEBUG: arch/ia64/config.in IA64_SGI_SN_SIM: arch/ia64/config.in MAPLE_KEYBOARD: arch/sh/config.in MAPLE_MOUSE: arch/sh/config.in PCIBA: arch/ia64/config.in PCI_PERMEDIA: arch/ppc/config.in PROFILE: arch/cris/config.in PROFILE_SHIFT: arch/cris/config.in SA1100_EXTENEX1: arch/arm/config.in SA1100_EXTENEX1_16MB: arch/arm/config.in SCSI_DECSII: drivers/scsi/Config.in SCSI_LASI: arch/parisc/config.in SERIAL_21285_OLD: drivers/char/Config.in ST40_LMI_MEMORY: arch/sh/config.in USERIAL: arch/m68k/config.in -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a Where rights secured by the Constitution are involved, there can be no rule making or legislation which would abrogate them. -- Miranda vs. Arizona, 384 US 436 p. 491 ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Missing Configure,help entries need filling in
We're down to 120 missing help entries. If you can fill some of these in, please send me a patch for Configure.help. ALPHA_EV67 ARCH_CDB89712 ARCH_CLEP7312 ARCH_EDB7211 ARC_CONSOLE ATM_LANAI AU1000_SERIAL_CONSOLE AU1000_UART BLK_DEV_IT8172 BLK_DEV_Q40IDE CPU_ARM1020_D_CACHE_ON CPU_ARM1020_FORCE_WRITE_THROUGH CPU_ARM1020_I_CACHE_ON CPU_ARM1020_ROUND_ROBIN CPU_ARM920_CPU_IDLE CPU_ARM920_D_CACHE_ON CPU_ARM920_I_CACHE_ON CPU_ARM920_WRITETHROUGH CPU_ARM926T CPU_ARM926_CPU_IDLE CPU_ARM926_D_CACHE_ON CPU_ARM926_I_CACHE_ON CPU_ARM926_ROUND_ROBIN CPU_ARM926_WRITETHROUGH CPU_FREQ DASD_AUTO_DIAG DASD_AUTO_ECKD DASD_AUTO_FBA DEBUG_RWLOCK DEBUG_SEMAPHORE EP7211_IR EP72XX_ROM_BOOT ETRAX_ETHERNET_LPSLAVE ETRAX_ETHERNET_LPSLAVE_HAS_LEDS ETRAX_NETWORK_LED_ON_WHEN_ACTIVITY ETRAX_NETWORK_LED_ON_WHEN_LINK ETRAX_POWERBUTTON_BIT ETRAX_ROOT_DEVICE ETRAX_SERIAL_PORT0 ETRAX_SHUTDOWN_BIT ETRAX_SOFT_SHUTDOWN EUROTECH_WDT EVB_PCI1 FB_TX3912 FORWARD_KEYBOARD GEN_RTC GSC_DINO HISAX_FRITZ_PCIPNP HWC_CPI I2C_ALGO8XX I2C_PPC405_ADAP I2C_PPC405_ALGO I2C_RPXLITE IA64_GRANULE_16MB IA64_GRANULE_64MB IA64_SGI_SN_DEBUG IA64_SGI_SN_SIM IT8172_REVC IT8172_SCR0 IT8172_SCR1 IT8172_TUNING ITE_I2C_ADAP ITE_I2C_ALGO LASI_82596 LP486E MAPLE_KEYBOARD MAPLE_MOUSE MIPS_AU1000_ENET MTD_ARM_INTEGRATOR PCIBA PCI_PERMEDIA PCMCIA_XIRCOM PFAULT PHONE_IXJ_PCMCIA PROFILE PROFILE_SHIFT SA1100_ADSBITSY SA1100_CERF_CPLD SA1100_EXTENEX1 SA1100_EXTENEX1_16MB SA1100_FIR SA1100_FREEBIRD SA1100_GRAPHICSMASTER SA1100_HUW_WEBPANEL SA1100_ITSY SA1100_JORNADA720 SA1100_OMNIMETER SA1100_PFS168 SA1100_PLEB SA1100_SHERMAN SA1100_SIMPAD SA1100_YOPY SCSI_DECSII SCSI_LASI SCSI_QLOGIC_FC_FIRMWARE SERIAL_21285_OLD SERIAL_SGI_L1_PROTOCOL SERIAL_TX3912 SERIAL_TX3912_CONSOLE SGIWD93_SCSI SHARED_KERNEL SOUND_CMPCI_FM SOUND_CMPCI_FMIO SOUND_CMPCI_LINE_BASS SOUND_CMPCI_LINE_REAR SOUND_CMPCI_MIDI SOUND_CMPCI_MPUIO SOUND_CMPCI_SPDIFINVERSE SOUND_VRC5477 ST40_LMI_MEMORY UCODE_PATCH USB_STORAGE_DATAFAB USB_STORAGE_HP8200e USB_STORAGE_JUMPSHOT USERIAL VETH VIA_RHINE_MMIO VIDEO_ZORAN_DC10 VIDEO_ZORAN_LML33 VLAN_8021Q -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a Gun Control: The theory that a woman found dead in an alley, raped and strangled with her panty hose, is somehow morally superior to a woman explaining to police how her attacker got that fatal bullet wound. -- L. Neil Smith ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: get_versions.sh
Giacomo Catenazzi [EMAIL PROTECTED]: Now I remember that you propose to me to detect the version of tools and program, to give user some warning about dangerous configurations in CML2. IIRC I've already annonced a the release of that file some time ago. Anyway, if you still intend to support it into CML2, tell me so that I will update it. CONFIG_GCC=y CONFIG_GCC_VERSION=2.96 CONFIG_GNU_MAKE=y CONFIG_MAKE_VERSION=3.79.1 CONFIG_GNU_LD=y CONFIG_LD_VERSION=2.11.90.0.8 CONFIG_LINUX_LSMOD=y CONFIG_MODUTILS_VERSION=2.4.6 CONFIG_UTIL_LINUX=y CONFIG_UTIL_LINUX_VERSION=2.11g which: no pppd in (.:/home/esr/bin:/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/sbin/:/usr/sbin:/sbin:/usr/local/sbin:/usr/sbin) CONFIG_E2FS=y CONFIG_E2FS_VERSION=1.23 which: no cardmgr in (.:/home/esr/bin:/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/sbin/:/usr/sbin:/sbin:/usr/local/sbin:/usr/sbin) Looks like a good start. For CML2 purposes you should string-quote the version numbers. Also you probably don't want the which output lines in there. autoconfigure seems to fail... snark:~/src$ sh autoconfigure.sh Begin of Autodetection autoconfigure.sh: EOF: command not found Parsing configuration database Tip: call 'modprobe -aq * ' before run autoprobe [please wait] Main detection finished autoconfigure.sh: 1151able: value too great for base (error token is 1151able)snark:~/src$ But I see what you're driving at here. Yes, I think these scripts should be integrated. We'll need to have CML2 and kbuild-2.5 in the tree to do it properly, I think, so it's phase 3. Keith, what are you thinking now about integration order? New makefiles first or CML2 first? -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a I hold it, that a little rebellion, now and then, is a good thing, and as necessary in the political world as storms in the physical. -- Thomas Jefferson, Letter to James Madison, January 30, 1787 ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Re: get_versions.sh
Giacomo A. Catenazzi [EMAIL PROTECTED]: A lot of script rely on empty output of failing which (and without the special syntax for shell aliases). Only wednesday I will have access to a RH machine, so can you confirm that the error of which are printed on stderr? snark:~/src/linux-2.5.1-pre3$ which foo /usr/bin/which: no foo in (.:/home/esr/bin:/usr/loca R6/bin:/sbin/:/usr/sbin) snark:~/src/linux-2.5.1-pre3$ which foo 2/dev/null snark:~/src/linux-2.5.1-pre3$ Looks like it, all right. -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a According to the National Crime Survey administered by the Bureau of the Census and the National Institute of Justice, it was found that only 12 percent of those who use a gun to resist assault are injured, as are 17 percent of those who use a gun to resist robbery. These percentages are 27 and 25 percent, respectively, if they passively comply with the felon's demands. Three times as many were injured if they used other means of resistance. -- G. Kleck, Policy Lessons from Recent Gun Control Research, Law and Contemporary Problems 49, no. 1. (Winter 1986.): 35-62. ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: Update order for Linus
Keith Owens [EMAIL PROTECTED]: I have been trying to add CML2 support to kbuild 2.5 but I have hit some CML2 problems, the latest being 1.9.3 displaying all the options instead of suppressing them. Since that problem should affect everybody, I think that kbuild 2.5 should go in first while we get CML2 sorted out. I've fixed this visibility bug. The bug queue is, once again, empty. I'm willing for the Makefiles stuff to go in first. -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a Everything you know is wrong. But some of it is a useful first approximation. ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] CML2 choice funny
Keith Owens [EMAIL PROTECTED]: Ugh. That's nasty. Can you imagine a change in the spec language that would make this unnecessary? The problem is the default which needs to vary from one arch to another. i386 defaults to bzImage, ia64 to vmlinuz etc. The default choice for one arch may be completely suppressed on another arch. The only way I can see round that is to make the default a variable rather than a string, which introduces its own problems. Right, I see this part. The other part of the problem is deciding which kernel format choices to suppress. Writing unless (ia64 or x86 or sparc or sparc64 or ...) suppress VMLINUZ is nasty, it really needs the reverse of suppress. Default to suppress, select if any of several conditions are true. unsuppress VMLINUZ if x86 unsuppress VMLINUZ if ia64 unsuppress VMLINUZ if sparc then the unsuppress commands can be in the arch specific rules.cml, instead of one big rule that has to be updated for each new arch. The reason that there is no unsuppress is that the default value of the visibility predicate is y. Unsuppresses wouldn't be meaningfuly unless you wrote unless n suppress VMLINUZ somewhere. I'm not sure it is worth the effort to change CML2, I can get the same effect by defining per arch symbols. John Cowan has proposed allowing the default expression in a choice to be a string-valued derive that must be the name of a choice. This kind of type punning makes me cringe, and anyway it would be hard to check at compile time that the returned string is necessarily valid. I think I may have a better idea. Let the default be a ? : name-valued expression. So your format choice could look something like this: choices kernel_format VMLINUX VMLINUZ IMAGE ZIMAGE BZIMAGE default ((X86 or IA64 or SPARC) ? VMLINUZ : BZIMAGE) This kind of expression would be pretty easy to check at compile time. I'm going to stare at the code for a while and scope out what it would actually take to implement this. -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a Probably fewer than 2% of handguns and well under 1% of all guns will ever be involved in a violent crime. Thus, the problem of criminal gun violence is concentrated within a very small subset of gun owners, indicating that gun control aimed at the general population faces a serious needle-in-the-haystack problem. -- Gary Kleck, Point Blank: Handgun Violence In America ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] CML2 choice funny
Tom Rini [EMAIL PROTECTED]: I don't know. How is it harder to validate choice kernel_format_PPC VMLINUX ZIMAGE ZNETBOOT default ZIMAGE choice kernel_format_ix86 VMLINUX ZIMAGE BZIMAGE BZDISK default BZIMAGE Than: choice kernel_format VMLINUX ZIMAGE BZIMAGE ZNETBOOT defeult ((X86) : BZIMAGE ? ((IA64 or SPARC) ? VMLINUZ : ZIMAGE)) unless X86 suppress BZIMAGE unless PPC suppress ZNETBOOT That's not a bad case. The case I'm worried about is the one where the choice menus get split into different files and can't be eyeballed at the same time easily. There's a problem like this now with unless/suppress declarations, but I saw no way to avoid it there. I guess I didn't read the other posts thourghly enough, what's the exact problem? Information distributed through the ruleset in such a way that it's hard to know all the places a given symbol participates. -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a Never trust a man who praises compassion while pointing a gun at you. ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] CML2 choice funny
Tom Rini [EMAIL PROTECTED]: Information distributed through the ruleset in such a way that it's hard to know all the places a given symbol participates. On the compiler side of things or the human side of things? It's the human side I'm primarily worried about. All of the rule files become one big file, sort of anyhow don't they? No, they don't. There's a top-level file that sources all then others at compilation time. -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a The politician attempts to remedy the evil by increasing the very thing that caused the evil in the first place: legal plunder. -- Frederick Bastiat ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] CML2 choice funny
Tom Rini [EMAIL PROTECTED]: Then what's wrong with putting these in arch/$(ARCH)/rules.cml, or arch/$(ARCH)/boot/rules.cml ? Nothing. But if they aren't single declarations, what's going to *keep* them there? -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a Question with boldness even the existence of a God; because, if there be one, he must more approve the homage of reason, than that of blindfolded fear Do not be frightened from this inquiry from any fear of its consequences. If it ends in the belief that there is no God, you will find incitements to virtue in the comfort and pleasantness you feel in its exercise... -- Thomas Jefferson, in a 1787 letter to his nephew ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] CML2 1.9.3 is available
The latest version is always available at http://www.tuxedo.org/~esr/cml2/ Release 1.9.3: Thu Nov 29 17:16:57 EST 2001 * Oops -- make sure Configure.help is included in the tarball! * Rulebase update for SOUND_IT8172. * Go back to using -I for oldconfig. I made an error in my release packaging. Thanks to David Relson for pointing it out. -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a What is a magician but a practicing theorist? -- Obi-Wan Kenobi, 'Return of the Jedi' ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] CML2 choice funny
Keith Owens [EMAIL PROTECTED]: In my never ending quest to try something stupid: choices kernel_format # The format that the kernel is to be compiled in VMLINUX VMLINUZ BZIMAGE ZIMAGE default BZIMAGE unless IA64 suppress VMLINUZ BZIMAGE ZIMAGE Will set BZIMAGE because it is the default, even though it has been suppressed. Yoicks. Maybe I'd better put in a compile-time check for default suppression! I am having some problems with the kernel format option, every arch needs this option but the choice list and default will vary between architectures. I am slowly coming to the conclusion that I need kernel_format_x86, kernel_format_ia64 etc. then suppress the entire choice for each arch rather than trying to suppress individual options on a common entry. Ugh. That's nasty. Can you imagine a change in the spec language that would make this unnecessary? -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a Of all tyrannies, a tyranny exercised for the good of its victims may be the most oppressive. It may be better to live under robber barons than under omnipotent moral busybodies. The robber baron's cruelty may sometimes sleep, his cupidity may at some point be satiated; but those who torment us for our own good will torment us without end, for they do so with the approval of their consciences. -- C. S. Lewis ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: Extending CML2 menus
Keith Owens [EMAIL PROTECTED]: For kbuild 2.5 I need to add a couple of sub-menus on the end of the main menu. How do I do that? The obvious attempt at extending the menu did not work. I defined rules-2.5.cml containing this source rules.cml symbols FOO 'foo' BAR 'bar' kao 'kao' menu kao# kao FOO BAR menu main kao It sort of works. kao appears at the end of the main menu but it appears as a data item instead of another menu. Yes, that's how it should work -- if you click on `kao' you should find yourself in the submenu. Also it is conditioned by the visibility of the previous menu (kernel debugging). That's odd. I'll try to reproduce that Try this: source rules.cml symbols FOO 'foo' BAR 'bar' menu main FOO BAR This should add FOO and BAR entries to the main menu. -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a Those who make peaceful revolution impossible will make violent revolution inevitable. -- John F. Kennedy ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: Extending CML2 menus
Keith Owens [EMAIL PROTECTED]: For kbuild 2.5 I need to add a couple of sub-menus on the end of the main menu. How do I do that? The obvious attempt at extending the menu did not work. I defined rules-2.5.cml containing this source rules.cml symbols FOO 'foo' BAR 'bar' kao 'kao' menu kao# kao FOO BAR menu main kao It sort of works. kao appears at the end of the main menu but it appears as a data item instead of another menu. Also it is conditioned by the visibility of the previous menu (kernel debugging). Dynamic extension of menus is required to support separate compilation, e.g. a new file system will extend the fs menu. OK, there were two errors here. First, the above snippet declares `kao' as a symbol and then annotates it as a menu. I have added code to detect this case and complain. Second, you had EXPERT off and didn't supply a help entry for kao, so it was rendered invisible. Try this: source rules.cml symbols FOO 'foo' BAR 'bar' menus kao kaos's sample menu menu kao# kao FOO BAR menu main kao Be sure to enable EXPERT. -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a Experience should teach us to be most on our guard to protect liberty when the government's purposes are beneficient...The greatest dangers to liberty lurk in insidious encroachment by men of zeal, well meaning but without understanding. -- Supreme Court Justice Louis Brandeis ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: CML 1.9.0 menuconfig loop
Keith Owens [EMAIL PROTECTED]: I got a loop in CML2 1.9.0 make menuconfig on a minimal config.out created by CML2 make oldconfig. The end of the debug shows is_visible(watchdog) called watchdog not visible, ancestor WATCHDOG false is_visible(kernelhacking) called kernelhacking not visible, kernelhacking guard WIZARD is false MenuBrowser.selected(): at 0, object=@135356244, 0 MenuBrowser.selected(): at 0, object=@135356244, 0 MenuBrowser.pop(): stack is empty.MenuBrowser.push(): pushing [arch]=@138701756, selection=arch MenuBrowser.push(): selection set to 0 MenuBrowser.push(): pushed [arch]=@138701756-1, selection=0, viewbase=0 MenuBrowser.selected(): at 0, object=@138701756, 0 MenuBrowser.selected(): at 0, object=@138701756, 0 MenuBrowser.down(): at level=0, object=@138701756, old selection=0, new selection = 0, new base = 0 MenuBrowser.selected(): at 0, object=@138701756, 0 MenuBrowser.selected(): at 0, object=@138701756, 0 MenuBrowser.down(): at level=0, object=@138701756, old selection=0, new selection = 0, new base = 0 MenuBrowser.selected(): at 0, object=@138701756, 0 MenuBrowser.selected(): at 0, object=@138701756, 0 And it loops. config.out and debug attached. The loop occurs with or without kbuild 2.5. This command works /usr/bin/python2 -O scripts/cmlconfigure.py -t -B 2.4.16 -I config.out rules.out This one loops /usr/bin/python2 -O scripts/cmlconfigure.py -c -DX86 -B 2.4.16 -i config.out rules.out Weird. I can't reproduce this -- and there seems to be something very wacked about your CML2 installation. The debug log claims that many symbols with help entries are invisible because they lack help entries (!)... I'll stare at that debug log some more... -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a Courage is resistance of fear, mastery of fear, not absence of fear. ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] CML2 1.9.1 is available
Keith Owens [EMAIL PROTECTED]: On Tue, 27 Nov 2001 13:39:44 -0500, Eric S. Raymond [EMAIL PROTECTED] wrote: Keith Owens has reported a looping bug I can't reproduce -- the bug log suggests that his CML2 rulebase is mis-installed somehow. The bug list is otherwise empty. The to-do list is empty. My fault. I had run install-cml2 then, for reasons that now escape me, I had copied symbols.cml from the cml2 tar ball. That removed all the merged help text, which caused cmlconfigure to loop. Well, that *is* a relief. I take bug reports from you quite seriously and this one had me worried. -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a The men and women who founded our country knew, by experience, that there are times when the free person's answer to oppressive government has to be delivered with a bullet. Thus, the right to bear arms is not just *a* freedom; it's the mother of all freedoms. Don't let them disarm you! ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] CML2 1.8.9 is available
Release 1.8.9: Wed Nov 21 15:10:29 EST 2001
* Sync with 2.4.15-pre8 (except for SH port).
* Attempted fix for FONT8x{8,16} rulebase bug reported by David
Relson.
--
a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a
An armed society is a polite society. Manners are good when one
may have to back up his acts with his life.
-- Robert A. Heinlein, Beyond This Horizon, 1942
___
kbuild-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] CML2 1.8.8 is available
Release 1.8.8: * Sync with 2.4.15-pre7 (except for SH port). -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a America is at that awkward stage. It's too late to work within the system, but too early to shoot the bastards. -- Claire Wolfe ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: CML2 1.8.6 is available -- bug list is cleared
Greg KH [EMAIL PROTECTED]: - CONFIG_USB_UHCI and CONFIG_USB_UHCI_ALT should be able to be selected as modules at the same time. Currently they are not. - USB Serial menu should be below USS720 parport driver - If USB_SERIAL = 'M' then USB_SERIAL_DEBUG should be not be shown. - HOTPLUG_PCI_COMPAQ should be tristate. Done for 1.8.7. - USB_SERIAL_IR does not show up in the menu, is this due to there not being a help entry for it? That's right. Symbols with no help are visible only when EXPERT is on. -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a That the said Constitution shall never be construed to authorize Congress to infringe the just liberty of the press or the rights of conscience; or to prevent the people of the United states who are peaceable citizens from keeping their own arms... -- Samuel Adams, in Phila. Independent Gazetteer, August 20, 1789 ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] CML 1.8.4 is available
Greg KH [EMAIL PROTECTED]: The following symbols should be allowed to be set to 'm' but are not: CONFIG_USB That's odd. M shows up as a choice when I do xconfig. CONFIG_UHCI CONFIG_UHCI_ALT My error. These are declared bool rather than trit in the 1.8.5 rulebase. I've just fixed tht. If CONFIG_USB_SERIAL is set to 'y' CONFIG_USB_SERIAL_DEBUG should be allowed to be chosen. I do not see this happening. Another rulebase bug, now fixed. And why is the CONFIG_USB_SERIAL options in the drivers/usb directory? In the CML1 version they live in their own subdirectory quite nicely :) Either way they should be in the USB port drivers section, not the USB devices section of the menu. Historical reasons. My rulebase was opriginally one big file for editing conveniece. What directory whould the USB serial stuff live in? There doesn't seem to be any rules set up for drivers/hotplug. What symbols should be in there, -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a Such are a well regulated militia, composed of the freeholders, citizen and husbandman, who take up arms to preserve their property, as individuals, and their rights as freemen. -- M.T. Cicero, in a newspaper letter of 1788 touching the militia referred to in the Second Amendment to the Constitution. ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] The 1.8.3 version of CML2 is available
Keith Owens [EMAIL PROTECTED]: If INPUT_GAMEPORT is selected *and* one of the drivers that uses gameport is built in then INPUT_GAMEPORT must also be built in. Otherwise there is no restriction on INPUT_GAMEPORT. OK, corrected for next release. -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a Of all tyrannies, a tyranny exercised for the good of its victims may be the most oppressive. It may be better to live under robber barons than under omnipotent moral busybodies. The robber baron's cruelty may sometimes sleep, his cupidity may at some point be satiated; but those who torment us for our own good will torment us without end, for they do so with the approval of their consciences. -- C. S. Lewis ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: CML2, how to set a string
Keith Owens [EMAIL PROTECTED]: On Mon, 12 Nov 2001 04:05:11 -0500, Eric S. Raymond [EMAIL PROTECTED] wrote: Keith Owens [EMAIL PROTECTED]: In CML2, how do you set a string variable that does not appear in a menu? CML1 for kbuild 2.5 has define_string CONFIG_KBUILD_CRITICAL CONFIG_SMP CONFIG_KBUILD_GCC_VERSION There isn't presently a way to do this. If you'll explain what you're trying to do with it, perhaps I can design an appropriate facility. KBUILD_CRITICAL lists all the config variables that are critical to the build. Any change in any of the listed variables forces a rebuild. A module with a different set of values for the critical variables will not be loaded without forcing. I need a variable that contains a list. I understand what you're trying to do, but not why CML2 has to be involved. What tests or operations do you need CML2 to be able to spport on lists, and what action do you want to trigger? -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a You have taught us much. Come with us and join the movement. This movement of yours, does it have slogans? inquired the Chink. Right on! they cried. And they quoted him some. Your movement, does it have a flag? asked the Chink. You bet! and they described their emblem. And does your movement have leaders? Great leaders. Then shove it up your butts, said the Chink. I have taught you nothing. -- Tom Robbins, Even Cowgirls Get The Blues ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
