[kbuild-devel] Re: CML2-2.1.3 is available
On January 15, 2002 08:37 pm, Rob Landley wrote: On Tuesday 15 January 2002 03:25 pm, Russell King wrote: On Tue, Jan 15, 2002 at 02:53:24PM -0500, Eric S. Raymond wrote: * The `vitality' flag is gone from the language. Instead, the autoprober detects the type of your root filesystem and forces its symbol to Y. This seems like a backwards step. What's the reasoning for breaking the ability to configure the kernel for a completely different machine to the one that you're running the configuration/build on? He didn't. If you want to do that, run make menuconfig instead of make autoconfigure. I detect a slight lack of symmetry here, shouldn't it be make autoconfig? Pardon me if this has been beaten to^W^W discussed above. -- Daniel ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Re: CML2-2.1.3 is available
Daniel Phillips wrote: I detect a slight lack of symmetry here, shouldn't it be make autoconfig? Pardon me if this has been beaten to^W^W discussed above. Yes. It should be make autoconfig, for symmterty reasons :-) I called the files and the project autoconfigure, because 'autoconfig' is already an utility made by GNU. (not related to kernel) giacomo ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Re: CML2-2.1.3 is available
On January 21, 2002 06:05 pm, Giacomo Catenazzi wrote: Daniel Phillips wrote: I detect a slight lack of symmetry here, shouldn't it be make autoconfig? Pardon me if this has been beaten to^W^W discussed above. Yes. It should be make autoconfig, for symmterty reasons :-) I called the files and the project autoconfigure, because 'autoconfig' is already an utility made by GNU. (not related to kernel) This is kernel autoconfig, different namespace, same idea. I don't think you have a problem. Besides, last time I checked, autoconfig wasn't copyrighted. -- Daniel ___ 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
Re: [kbuild-devel] Re: CML2-2.1.3 is available
Eric S. Raymond wrote: Kai Henningsen [EMAIL PROTECTED]: I think right now, the only halfway reasonable thing is to do what ttyname() does: get the devide number off stat(/), and search it in /dev. (Besides, you can figure out part of the answer - about as much as the autoprober does now - from the major anyway.) There's a swamp there -- getting from the major device number to the right config symbol seems like a long and tortuous process. First you have to get from major number to driver, then from driver to config symbol. I don'rt thing the metadata for either of these is present in the current driver infrastructure. Major number tell you what kind of device is attached: IDE, SCSI,... (Documentation/devices.txt). From this info, you parse the /proc/ide , /proc/scsi to see what driver is attached to a particular device. giacomo ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: CML2-2.1.3 is available
On Wed, Jan 16, 2002 at 11:38:40AM -0500, Ross Vandegrift wrote: [snip] I'm planning on trying this on a Debian testing box I have at work at some point. Just verified the same process works on Debian testing, as well as with cml2-2.1.3. Ross Vandegrift [EMAIL PROTECTED] ___ 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.3 is available
Eric S. Raymond [EMAIL PROTECTED] said: 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. 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. Now repeat after me, Horst: The autoconfigurator is *optional*, not required. It isn't optional, it is builtin. It doesn't matter if somebody uses it or nobody does, it will be there. And AFAIU what you have said, you are modifiying CML2 (or at least the rulebase) for the sake of it. This is _not_ what had been agreed on the matter. -- Horst von Brand http://counter.li.org # 22616 ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Re: CML2-2.1.3 is available
horst Whatever happened to Do exactly as CML1 does; leave fixes and extensions horst for later? If you put the kitchen sink into it, it _won't_ go into the horst standard kernel. My opinions: It's important that people who type make config or make oldconfig or make menuconfig or make xconfig will continue to have the same experience as they did before. Bug fixes that 90% or 95% of the users agree make things better are okay. Completely new features are okay. make autoconfigure is not going to change anyone's experience from CML1. The multiple questions about what if I want to configure for a different box indicate to me that Eric's product marketing needs a little work. The product itself is fine, but users are getting the idea that autoconfiguration is part of make config. I would recommend that Eric talk about make autoconfigure rather than the autoprober or autoconfigurator. That makes it more obvious (to me at least) that make autoconfigure is a new feature and does not mess with the established semantics of make config/oldconfig/menuconfig/xconfig. It's fun being retired. I get to pontificate without doing work. :) Michael Elizabeth Chastain mailto:[EMAIL PROTECTED] love without fear ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: CML2-2.1.3 is available
Eric, the way you worded the change report it sounded to many of us as if you were making the autoprober mandatory for detecting the root filesystem. That's why it spawned so many messages like this (including one from me yesterday) you should have added something in the changelog entry that said that this autoprobe only happened when you do an autoconfigure, as it is it implies that is is for every variaty of make *config. I understand why you are frustrated with the response, but it's not a case of people having thick skulls it's a case of you leaving out critical info from you changelog so people reading it without your mindset see it saying something that you didn't mean. remember most of us have no idea why the 'vitality' flag was there in the first place so we can't imply a limit on the autoprober that is replacing it. David Lang On Wed, 16 Jan 2002, Eric S. Raymond wrote: Date: Wed, 16 Jan 2002 16:31:44 -0500 From: Eric S. Raymond [EMAIL PROTECTED] To: Horst von Brand [EMAIL PROTECTED] Cc: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: 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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: CML2-2.1.3 is available
[EMAIL PROTECTED] said: 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. 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. -- dwmw2 ___ 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
[kbuild-devel] Re: CML2-2.1.3 is available
On Wednesday 16 January 2002 11:38 am, Ross Vandegrift wrote: At this point the rules are compiled and a dialog box indicates that Suppression has been turned off (press any key to continue). I hit any key and am presented with the first menu. Ah, I understand the bug. That dialog indicates that your existing .config (the one it loaded the symbols from) is setting a symbol that is ordinarily suppressed. (One your dependency list thinks you shouldn't have access to, like a piece of Alpha-only hardware during an X86 configuration session.) It found it, noticed that setting it would be inconsistent with the existing rulebase's dependencies, and let you know that it had to turn suppression off in order to access it. That's not the bug (although it implies that either your .config is really weird, or there's a rulebase error suppressing something that shouldn't be). It just triggers the bug. Turning off suppression will also make frozen symbols show up, as you noticed. This is where an old bug I already got Eric to patch resurfaced. :) The menu freezing bug is a menuconfig display problem. It happens because you can't select a frozen symbol: it skips to the next one when you cursor over it. If EVERY symbol in the menu is frozen, when you first try to display the menu it goes into an endless loop trying to figure our what symbol to put the cursor on. I told Eric about this earlier, and he hid all the frozen symbols (which he intended to do anyway). A menu with no visible symbols won't show up. But when you turn off suppression, the menu gets unhidden, and the bug comes back. Eric, you wanna take another swing at it? Rob ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: CML2-2.1.3 is available
On Tue, Jan 15, 2002 at 02:53:24PM -0500, Eric S. Raymond wrote: * The `vitality' flag is gone from the language. Instead, the autoprober detects the type of your root filesystem and forces its symbol to Y. This seems like a backwards step. What's the reasoning for breaking the ability to configure the kernel for a completely different machine to the one that you're running the configuration/build on? Answers including Aunt Tillies or Penelopes won't be accepted. 8) -- Russell King ([EMAIL PROTECTED])The developer of ARM Linux http://www.arm.linux.org.uk/personal/aboutme.html ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: CML2-2.1.3 is available
On Tue, 15 Jan 2002, Eric S. Raymond wrote: 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 * 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? Nicolas ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: CML2-2.1.3 is available
On Tue, 2002-01-15 at 14:53, Eric S. Raymond wrote: * The `vitality' flag is gone from the language. Instead, the autoprober detects the type of your root filesystem and forces its symbol to Y. And when I compile a kernel for my Dreamcast? Or when I want to change rootfs? Or how I just don't want the configurator enforcing policy? Robert Love ___ 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
On Tue, 15 Jan 2002, Eric S. Raymond wrote: 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. Sorry. I passed over autoprober too fast. As long as auto* stuff can be turned off that fine. Nicolas ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: CML2-2.1.3 is available
On Tue, 15 Jan 2002, Eric S. Raymond wrote: * The `vitality' flag is gone from the language. Instead, the autoprober detects the type of your root filesystem and forces its symbol to Y. can you override this autodetect? (it may not be valid if you are building on one machine for another) David Lang ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: CML2-2.1.3 is available
[esr] * The `vitality' flag is gone from the language. Instead, the autoprober detects the type of your root filesystem and forces its symbol to Y. [Russell King] This seems like a backwards step. What's the reasoning for breaking the ability to configure the kernel for a completely different machine to the one that you're running the configuration/build on? As Eric keeps saying - autoconfigure is OPTIONAL. It is merely one way to generate a .config, not the only way. Answers including Aunt Tillies or Penelopes won't be accepted. 8) (: Peter ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: CML2-2.1.3 is available
On Tuesday 15 January 2002 03:41 pm, Nicolas Pitre wrote: On Tue, 15 Jan 2002, Eric S. Raymond wrote: 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. Sorry. I passed over autoprober too fast. As long as auto* stuff can be turned off that fine. It's optional. I -STILL- can't figure out why the autoprober doesn't just look in /proc/mounts to figure out who and what our root device and filesystem are. I need to set up a system that boots to an initrd and puts the root device lives on a samba server just to confuse eric's autoprober. Hmmm... I wonder if that would work? :) Rob ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: CML2-2.1.3 is available
On Tuesday 15 January 2002 03:24 pm, Eric S. Raymond wrote:
To invoke the autoconfigurator, you do one of two things:
`make autoconfigure'
This runs the autoconfigurator in standalone mode. This gives you
an entire configuration, ready to build with.
`make autoprobe {config,menuconfig,xconfig}'
This runs the autoconfigurator in probe mode, which gives you
a report on facilities found (without making assumptions about facilities
not found). This report gets fed to your interactive configurator, which
then proceeds not to bother you with questions for which the autoprobe
report already gave it answers.
The ordinary make {config,menuconfig,xconfig} behaves as it always did.
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.)
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 :). So just run menuconfig twice and
you can edit everything that got autoprobed...
The user interface still has a couple of teething troubles, but they're
mostly in the new stuff that CML1 never attempted to do (like autoconfig).
(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...)
Rob
___
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] Re: CML2-2.1.3 is available
[esr] The version I just released does exactly that. Well, not exactly; it actually looks at fstab -- /proc/mounts gives you '/dev/root' rather than a physical device name in the root entry. /etc/fstab is hardly guaranteed to be accurate either. The kernel mounts the root device based on its command line and any pivot_root() calls you make, not based on /etc/fstab. [In practice, I imagine most people don't lie to fstab. The fsck init script would get annoyed.] But the horse's mouth, in this case, is /proc/sys/kernel/real-root-dev, a 16-bit decimal int which represents a device number in MAJOR*256+MINOR format. There *may* also the 'root=' asciiz string in /proc/cmdline, which will be a 4-digit hex number, but that is not reliable - because of pivot_root() among other things. On my system, real-root-dev gives 8453, which means /dev/hde5, which is on ide2. According to /proc/ide/ide2/config, it is a PCI device of type 105a:4d30 [Promise Ultra100], so you can derive CONFIG_BLK_DEV_PDC202XX as well as CONFIG_BLK_DEV_IDEDISK. Peter ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
