Re: [kbuild-devel] Removal of CPP and CPPFLAGS
On Fri, 18 May 2001 09:41:51 +0200 (CEST), Kai Germaschewski [EMAIL PROTECTED] wrote: On Fri, 18 May 2001, Keith Owens wrote: I plan to remove CPP and CPPFLAGS, replacing $(CPP) with $(CC) -E throughout and merging CPPFLAGS into [AC]FLAGS. This change will make it much easier to handle implicit dependencies in kbuild 2.5. I don't see this, can you explain it further? CFLAGS is set to $(CPPFLAGS) + compilation flags, whereas the preprocessing of course only needs $(CPPFLAGS). Well, currently it's not done cleanly at all, i.e. -D__MODULE__ -include ... etc. are added directly to the command line and aren't part of $(CPPFLAGS), but that's fixable. That is precisely my problem, it is not done cleanly at the moment. We currently have, in roughly this order global cppflags in top level makefile include list from top level makefile module/kernel flags from top level makefile global cflags in top level makefile extra cflags for entire directory from makefile extra cflags for individual file from makefile The last two are called EXTRA_CFLAGS and CFLAGS_$@, even though they almost always contain preprocessor flags. Some of the preprocessing steps are missing some flags, I just got a bug report that genksyms does not get extra cflags from the directory or file so the modversions calculation is not always correct. For 2.5 I want users to be able to specify extra flags at the global, directory and file level on the command line, without having to edit the makefile. We sometimes get patches sent out with debugging options turned on the makefile because somebody forgot to remove their debugging change. So the list will be global cflags from top level makefile global extra cflags from command line include list from top level makefile module/kernel flags from top level makefile extra cflags for entire directory from makefile extra cflags for entire directory from command line extra cflags for individual file from makefile extra cflags for individual file from command line If I maintain the semi-separation between preprocessor and other C flags then it gets very messy when most of the extra cflags are really being used for preproessing options. I would have to include almost all flags in the preprocessor steps anyway, just in case they affected cpp. So why have an artificial separation that only affects a couple of cases, has been a source of error and AFAICT provides no benefit? It is a lot easier to say that all steps get all flags and let the preprocessor and compiler work out which bits they want. ___ kbuild-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Removal of CPP and CPPFLAGS
On Fri, 18 May 2001, Keith Owens wrote: That is precisely my problem, it is not done cleanly at the moment. We currently have, in roughly this order global cppflags in top level makefile include list from top level makefile module/kernel flags from top level makefile global cflags in top level makefile extra cflags for entire directory from makefile extra cflags for individual file from makefile The last two are called EXTRA_CFLAGS and CFLAGS_$@, even though they almost always contain preprocessor flags. Some of the preprocessing steps are missing some flags, I just got a bug report that genksyms does not get extra cflags from the directory or file so the modversions calculation is not always correct. Okay, I see your point now. There's of course the option to have EXTRA_CPPFLAGS/CPPFLAGS_$@, but most likely Makefile writers will get this wrong, and it effectively doubles the number of FLAGS variables to track. If I maintain the semi-separation between preprocessor and other C flags then it gets very messy when most of the extra cflags are really being used for preproessing options. I would have to include almost all flags in the preprocessor steps anyway, just in case they affected cpp. So why have an artificial separation that only affects a couple of cases, has been a source of error and AFAICT provides no benefit? It is a lot easier to say that all steps get all flags and let the preprocessor and compiler work out which bits they want. Okay, I think you're right, the logical separation is not worth the additional complexity. But why not leave the CPP variable at least? --Kai ___ kbuild-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Removal of CPP and CPPFLAGS
On Fri, 18 May 2001 12:44:31 +0200 (CEST), Kai Germaschewski [EMAIL PROTECTED] wrote: Okay, I think you're right, the logical separation is not worth the additional complexity. But why not leave the CPP variable at least? On second thoughts I will keep CPP, it is a useful indication that the command just preprocesses instead of compiling. ___ kbuild-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Re: CML2 design philosophy heads-up
Christoph Hellwig wrote: On Fri, May 18, 2001 at 11:51:28AM -0400, John Cowan wrote: Jes Sorensen wrote: Telling them to install an updated gcc for kernel compilation is a necessary evil, which can easily be done without disturbing the rest of the system. Updating the system's python installation is not a reasonable request. Au contraire. It is very reasonable to have both python and python2 installed. Having two different gcc versions installed is a big pain in the arse. Fump. Some distributions do even come with two gcc's out of the box. With the whole egcs and gcc2.95 (dunno about 3.0) you can even share the compiler driver if you want. Yes, I should have limited myself to pre-egcs versions. -- There is / one art || John Cowan [EMAIL PROTECTED] no more / no less || http://www.reutershealth.com to do / all things || http://www.ccil.org/~cowan with art- / lessness \\ -- Piet Hein ___ kbuild-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Re: CML2 design philosophy heads-up
On Fri, 18 May 2001, Eric S. Raymond wrote: That being the case, we do face a question of design philosophy, expressed as a policy question about how to design rulesets. Actually two questions: 1. When we have a platform symbol for a reference design like MVME147, do we stick to its spec sheet or consider it representative of all derivatives (which may have other facilities)? I know my answer to this one, which I will implement unless there's strong consensus otherwise. I go for explicitness. If we're going to support MVME147 derivatives and variants in the ruleset, they get their own platform symbols. I believe it's important two distinguish between two things here, auto-configuration and normal configuration. One should take care to not mix these things up. Of course I don't know about the specific hardware there, but I believe selecting NVME147 will give you arch specific code which will cope with general aspects of that board, but also for derived designs. That makes sense, and no need to introduce different config symbols at that level. I'd call CONFIG symbols like that basic, and they should be described by a ruleset which ensures that building the kernel will actually work, and that you have a chance that it even runs. (Things like a SCSI driver requires the SCSI midlayer, etc. which would normally lead to unresolved symbols or the inability to load the driver module into the running kernel later). On the other hand, for some people it would be nice to say I've got the reference board, build the right kernel. That's okay, but it should be another option, and rules like that should be in a separate files, so they don't clutter up the basic rulesets. So, leave the flexibility to people who need, and on top of that you can have a mechanism which allows easier configuration for people who don't want to care about the details. However, more important there would be some option like build me a kernel for the hardware I'm currently running on (and let the user fine tune afterwards). --Kai ___ kbuild-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: CML2 design philosophy heads-up
Alan Cox [EMAIL PROTECTED]: I don't want to do (a); it conflicts with my design objective of simplifying configuration enough that Aunt Tillie can do it. I won't do that unless I see a strong consensus that it's the only Right Thing. Its a good way of getting the defaults right. It may also be an appropriate way of guiding presentation (eg putting the stuff the ruleset says you wont have under a subcategory so you would see CPU type Devices blah blah Other Options IDE disk Cardbus I want to understand what you're driving at here and I don't get it. What's the referent of Its? Are you saying you think Aunt Tillie's view of the world should guide the presentation of options? -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a Are we at last brought to such a humiliating and debasing degradation, that we cannot be trusted with arms for our own defence? Where is the difference between having our arms in our own possession and under our own direction, and having them under the management of Congress? If our defence be the *real* object of having those arms, in whose hands can they be trusted with more propriety, or equal safety to us, as in our own hands? -- Patrick Henry, speech of June 9 1788 ___ kbuild-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Re: CML2 design philosophy heads-up
Michael Meissner [EMAIL PROTECTED]: On Fri, May 18, 2001 at 06:09:09PM +0200, Christoph Hellwig wrote: Aunt Tillie shouldn't try to manually configure a kernel. Ummm, maybe Aunt Tillie wants to learn how to configure a kernel After all, all of us at one point in time were newbies in terms of configuring kernels, etc. And if she doesn't, maybe her teenage daughter Muffy wants to learn. You know, the one with the unicorn appliques and the pink scrunchies and the Back Street Boys posters in her bedroom? Dammit, if we're serious about empowering people with free software we can't limit ourselves with the attitude that configuring kernels (or anything else) is the sacred preserve of a geek elite. -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a The price of liberty is, always has been, and always will be blood. The person who is not willing to die for his liberty has already lost it to the first scoundrel who is willing to risk dying to violate that person's liberty. Are you free? -- Andrew Ford ___ kbuild-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Re: CML2 design philosophy heads-up
Hi Alan, CML1 has had no official maintainer for about 4 years. People contribute bits and it works. So as it stands there would be no reason to remove it. Actually, I actively maintained all three config tools for several months just before the 2.2 release (January 1999). Then I went back to work and it's been neglected since then. It just feels like 4 years in Linux time. Michael ___ kbuild-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Re: CML2 design philosophy heads-up
My two cents: I'm in favor of a new description language. I'm in favor of new tools for processing it. I'm comfortable with Python as an implementation language. The speed problems seem to be under control. It would be nice if either (a) the tools ran with Python 1.5.2 or (b) some more time elapses and lots more people have Python 2.0 installed. I think the transition to a new language is so big that anything controversial about the config files themselves should not be part of the transition. Just translate the CML1 files directly into CML2. If someone says such-and-such is yucky, the defense is: the CML2 version is less yucky or equally yucky as CML1 was. After the transition, then have discussions about re-designing the actual style of the files. Let the arch maintainers be in charge of their files. We used to have a lot of problems with arch maintainers writing stuff that didn't work with all three config programs. Then I realized there's never been a spec for this stuff. So I wrote Documentation/kbuild/config-language.txt, and it became a lot easier for people to write good Config.in files. Andrzej Krzysztofowicz also went through all the places in the spec where xconfig had documented silly restrictions, and fixed them in xconfig. If there's a good language spec, and good tools that actually report language errors, arch maintainers and subsystem maintainers can take care of their own files. Michael ___ kbuild-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Re: CML2 design philosophy heads-up
Michael Elizabeth Chastain [EMAIL PROTECTED]: My two cents: I'm in favor of a new description language. I'm in favor of new tools for processing it. If you, wearing your CML1 maintainer hat, hadn't made these things clear a year ago ago, CML2 wouldn't exist today. I'm comfortable with Python as an implementation language. The speed problems seem to be under control. Linus is comfortable with it too. That argument seems to be over for everyone but Jes Sorensen. In any case, Greg Banks is tracking the Python implementation in C (though I don't think he has the theorem prover working yet). It would be nice if either (a) the tools ran with Python 1.5.2 or (b) some more time elapses and lots more people have Python 2.0 installed. I think we'll get (b). 2.5 will be bleeding edge by definition; I'm not worried about anyone working on an unstable branch being unable to install Python 2.0. And 2.6 is 18 to 24 months out. By the time Python 2.0 is needed for a stable-branch build, it will be ubiquitous. I think the transition to a new language is so big that anything controversial about the config files themselves should not be part of the transition. Just translate the CML1 files directly into CML2. If someone says such-and-such is yucky, the defense is: the CML2 version is less yucky or equally yucky as CML1 was. That's exactly the approach I've taken until very recently. But the compiler and configurator codebase is stable now. It seemed to me time to think about improving the rulebase. I started this CML2 design philosophy heads-up precisely because I didn't want to redesign the rulebase without a lot of input and explicit discussion. Let the arch maintainers be in charge of their files. I'm totally in favor of that. No way do I want to maintain the rulebase myself! -- 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] http://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Re: CML2 design philosophy heads-up
Eric Raymond writes: That's exactly the approach I've taken until very recently. But the compiler and configurator codebase is stable now. It seemed to me time to think about improving the rulebase. Ah, that is where we have different views. I think CML2 would be better off if you shelved improving the rulebase and focussed on integrating into the kernel. I'm not very good at getting things integrated into the kernel (it took me a year to get CONFIG_SMP in). Alan is certainly an expert on integration hurdles. Do you have a checklist from Linus about what he wants to see? Michael ___ kbuild-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Re: CML2 design philosophy heads-up
Michael Elizabeth Chastain [EMAIL PROTECTED]: Ah, that is where we have different views. I think CML2 would be better off if you shelved improving the rulebase and focussed on integrating into the kernel. It's a drop-in install now. Is there something else specific you think I could be doing? I'm not very good at getting things integrated into the kernel (it took me a year to get CONFIG_SMP in). Alan is certainly an expert on integration hurdles. Alan is occasionally an expert at *producing* integration hurdles. I'm the official Configure.help maintainer, I've got a version that covers both the ac and Linus trees and contains more than 340 help entries now missing, and I haven't seen it in a mainline tree yet. Do you have a checklist from Linus about what he wants to see? There was one (the big item was that he wanted the rulebase split into per-directory files), but to the best of my knowledge I've fulfilled it. -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a As with the Christian religion, the worst advertisement for Socialism is its adherents. -- George Orwell ___ kbuild-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Re: CML2 design philosophy heads-up
On Fri, 18 May 2001 14:41:22 -0400, Eric S. Raymond [EMAIL PROTECTED] wrote: Michael Elizabeth Chastain [EMAIL PROTECTED]: It would be nice if either (a) the tools ran with Python 1.5.2 or (b) some more time elapses and lots more people have Python 2.0 installed. I think we'll get (b). 2.5 will be bleeding edge by definition; I'm not worried about anyone working on an unstable branch being unable to install Python 2.0. And 2.6 is 18 to 24 months out. By the time Python 2.0 is needed for a stable-branch build, it will be ubiquitous. Please, please never loose sight of the requirement for kbuild to work on non-Linux platforms. People cross compile kernels from Solaris, HP/UX, Cygwin, etc. kbuild should run on any platform that has gcc, binutils and textutils. Any requirements to build a kernel beyond that list starts getting awkward. ___ kbuild-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Re: CML2 design philosophy heads-up
Keith Owens [EMAIL PROTECTED]: Please, please never loose sight of the requirement for kbuild to work on non-Linux platforms. People cross compile kernels from Solaris, HP/UX, Cygwin, etc. Python 2.0 runs quite nicely under the Macintosh OS, other Unixes and Cygwin. You could even cross-configure from a Windows box if you wanted to do such a thing. -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a Non-cooperation with evil is as much a duty as cooperation with good. -- Mohandas Gandhi ___ kbuild-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: CML2 design philosophy heads-up
Alan Cox [EMAIL PROTECTED]: I was under the impression the MVME had VME bus. So you can hang IDE off it and other gunge. Its also a reference design so you may find MVME147 like boards.. Urk. Alan is right, I misinterpreted the original question. There is no on-board support for IDE or PCMCIA, but you could plug in an IDE daughterboard with an IDE drive or a PCMCIA slot. This would be a pretty damn perverse thing to do, however -- there are newer, less expensive, faster, and generally better SBCs that have IDE/ATAPI and PCMCIA built in. On top of that, VMEbus SBCs aren't normally used for consumer devices -- their market is basically industrial-control applications with a side of scientific instrumentation. That being the case, we do face a question of design philosophy, expressed as a policy question about how to design rulesets. Actually two questions: 1. When we have a platform symbol for a reference design like MVME147, do we stick to its spec sheet or consider it representative of all derivatives (which may have other facilities)? I know my answer to this one, which I will implement unless there's strong consensus otherwise. I go for explicitness. If we're going to support MVME147 derivatives and variants in the ruleset, they get their own platform symbols. 2. How much extra tsuris should we accept in order to handle perverse edge cases like this one? There are three ways we can cope: (a) Back off the capability approach. That is, accept that people doing configuration are going to explicitly and exhaustively specify low-level hardware. (b) Add complexity to the ruleset. Split SCSI into SCSI_MIDLEVEL and SCSI_DRIVERS capabilities, make sure SCSI_DRIVERS is implied whenever a SCSI card is configured, etc. (c) Decide not to support this case and document the fact in the rulesfile. If you're going put gunge on the VME bus that replaces the SBC's on-board facilities, you can hand-hack your own configs. I don't want to do (a); it conflicts with my design objective of simplifying configuration enough that Aunt Tillie can do it. I won't do that unless I see a strong consensus that it's the only Right Thing. The larger question in choosing between (b) and (c) is one of the usual ones in programming -- that is, generality vs. maintainability. Is it ever acceptable for the configuration system to deliberately punt an edge case like this one in order to keep from having a combinatorial-complexity explosion in the ruleset? I know what my sense of taste and proportion says. But I'm not going to impose my vision on everybody. If you have an opinion, I'd like to hear it. -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a Whether the authorities be invaders or merely local tyrants, the effect of such [gun control] laws is to place the individual at the mercy of the state, unable to resist. -- Robert Anson Heinlein, 1949 ___ kbuild-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: CML2 design philosophy heads-up
Keith == Keith Owens [EMAIL PROTECTED] writes: Keith cc trimmed back to mailing lists only. On Fri, 18 May 2001 Keith 10:53:53 -0400, Eric S. Raymond [EMAIL PROTECTED] wrote: (a) Back off the capability approach. That is, accept that people doing configuration are going to explicitly and exhaustively specify low-level hardware. Keith No, you loose one of the nicer features of CML2. No, explicit selection *must* be available as an option. Jes ___ kbuild-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Re: CML2 design philosophy heads-up
For CML1 and CML2 to handle the same language, we would either have to live with the CML1 language's limitations or retrofit the old tools to speak CML2 language. The chance of the latter happening is, I think we can agree, effectively zero. Being able to turn CML2 into CML1 might be the more useful exercise. Alan ___ kbuild-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Re: CML2 design philosophy heads-up
On Fri, May 18, 2001 at 12:34:13PM -0400, Eric S. Raymond wrote: Even supposing somebody were loony enough to do that, how would preserving an old interface in amber do anything to explore new UI possibilities? I don't know about the rest of the world, but I _much_ prefer the old menuconfig to CML2's menuconfig. While I haven't spent much time playing with CML2, I'm familiar with cml1's tools and see no reason why they need changes, which IMHO (so far) are detrimental. That's not even to mention python issues, speed, or anything else. ___ kbuild-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] CML2 1.4.5 is available
The latest version is always available at http://www.tuxedo.org/~esr/cml2/ Release 1.4.5: Fri May 18 02:02:27 EDT 2001 * Rulesfile updated for 2.4.5pre3, 2.4.4ac10. The project page now also includes a download URL for the latest version of the Configure.help file. It features over 340 entries that are missing in the one Linus and Alan are shipping. -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a The best we can hope for concerning the people at large is that they be properly armed. -- Alexander Hamilton, The Federalist Papers at 184-188 ___ kbuild-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Re: CML2 design philosophy heads-up
Jes Sorensen wrote: Telling them to install an updated gcc for kernel compilation is a necessary evil, which can easily be done without disturbing the rest of the system. Updating the system's python installation is not a reasonable request. Au contraire. It is very reasonable to have both python and python2 installed. Having two different gcc versions installed is a big pain in the arse. So far I haven't heard a single developer say something positive about CML2, the most positive I have heard so far has been whatever, it's his choice, I don't care, I want to hack. The majority are of the NO! and you got to be kiddin'. Anonymized hearsay evidence is less than convincing. Let's just say you didn't exactly give peoiple a good impression with the trolling around on how everybody had to change their option names and how important it was for the world. Decidedly bad form to criticize someone for a bug (in this case, a design bug) that's already been fixed. If that behavior starts, who shall escape hanging? I do not have Python2 installed and I do not plan to, if you change CML2 to use a reasonable programming language I might give it a try. Those who don't remember the past are condemned to repeat it. John Cowan, _novus homo_ (Latin for upstart) -- There is / one art || John Cowan [EMAIL PROTECTED] no more / no less || http://www.reutershealth.com to do / all things || http://www.ccil.org/~cowan with art- / lessness \\ -- Piet Hein ___ kbuild-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: CML2 design philosophy heads-up
(c) Decide not to support this case and document the fact in the rulesfile. If you're going put gunge on the VME bus that replaces the SBC's on-board facilities, you can hand-hack your own configs. In general this is the best option, if you create a non-standard configuration for machine foo then it is your problem, not everybody else's. Which makes CML2 inferior to CML1 again. Now if it could parse CML1 rulesets this whole discussion wouldn't be needed. ___ kbuild-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Re: CML2 design philosophy heads-up
That's ok as long as she doesn't add backstreet boys songtexts as long as your signature to her mails. I wouldn't worry. She'd be swimming to Cuba in search of asylum from the MPAA if she did Your point is basically: Lets rewrite the kernel in VBA to make every word user capable of driver hacking. I think thats a bit unfair. Changing the description language so drastically is the big problem, not the tools or its UI. Its 'and Im forking the config language from under every other config tool including the kde work and mconfig' ___ kbuild-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Re: CML2 design philosophy heads-up
On Fri, May 18, 2001 at 12:04:34PM -0400, Eric S. Raymond wrote: Alan Cox [EMAIL PROTECTED]: I don't want to do (a); it conflicts with my design objective of simplifying configuration enough that Aunt Tillie can do it. I won't do that unless I see a strong consensus that it's the only Right Thing. Its a good way of getting the defaults right. It may also be an appropriate way of guiding presentation (eg putting the stuff the ruleset says you wont have under a subcategory so you would see CPU type Devices blah blah Other Options IDE disk Cardbus I want to understand what you're driving at here and I don't get it. What's the referent of Its? Are you saying you think Aunt Tillie's view of the world should guide the presentation of options? Aunt Tillie shouldn't try to manually configure a kernel. Christoph P.S. _please_ shorten your .sig -- Whip me. Beat me. Make me maintain AIX. ___ kbuild-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: CML2 design philosophy heads-up
if you punt in case C you should then have a mode where all dependancies are ignored and all options are presented to the person ding the config. This is FAR better then forcing them to hand-hack the config file. possibly split the rules file into two parts. part 1. absolute requirements (i.e. if you select a SCSI controller you MUST select SCSI) part 2. simplifications (i.e. if x86 and printer then x86_printer) tehn have a mode where the part 2 rules are not evaluated to handle the corner cases. David Lang On Fri, 18 May 2001, Eric S. Raymond wrote: Date: Fri, 18 May 2001 10:53:53 -0400 From: Eric S. Raymond [EMAIL PROTECTED] To: Alan Cox [EMAIL PROTECTED] Cc: Tom Rini [EMAIL PROTECTED], Michael Meissner [EMAIL PROTECTED], Keith Owens [EMAIL PROTECTED], CML2 [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: CML2 design philosophy heads-up Alan Cox [EMAIL PROTECTED]: I was under the impression the MVME had VME bus. So you can hang IDE off it and other gunge. Its also a reference design so you may find MVME147 like boards.. Urk. Alan is right, I misinterpreted the original question. There is no on-board support for IDE or PCMCIA, but you could plug in an IDE daughterboard with an IDE drive or a PCMCIA slot. This would be a pretty damn perverse thing to do, however -- there are newer, less expensive, faster, and generally better SBCs that have IDE/ATAPI and PCMCIA built in. On top of that, VMEbus SBCs aren't normally used for consumer devices -- their market is basically industrial-control applications with a side of scientific instrumentation. That being the case, we do face a question of design philosophy, expressed as a policy question about how to design rulesets. Actually two questions: 1. When we have a platform symbol for a reference design like MVME147, do we stick to its spec sheet or consider it representative of all derivatives (which may have other facilities)? I know my answer to this one, which I will implement unless there's strong consensus otherwise. I go for explicitness. If we're going to support MVME147 derivatives and variants in the ruleset, they get their own platform symbols. 2. How much extra tsuris should we accept in order to handle perverse edge cases like this one? There are three ways we can cope: (a) Back off the capability approach. That is, accept that people doing configuration are going to explicitly and exhaustively specify low-level hardware. (b) Add complexity to the ruleset. Split SCSI into SCSI_MIDLEVEL and SCSI_DRIVERS capabilities, make sure SCSI_DRIVERS is implied whenever a SCSI card is configured, etc. (c) Decide not to support this case and document the fact in the rulesfile. If you're going put gunge on the VME bus that replaces the SBC's on-board facilities, you can hand-hack your own configs. I don't want to do (a); it conflicts with my design objective of simplifying configuration enough that Aunt Tillie can do it. I won't do that unless I see a strong consensus that it's the only Right Thing. The larger question in choosing between (b) and (c) is one of the usual ones in programming -- that is, generality vs. maintainability. Is it ever acceptable for the configuration system to deliberately punt an edge case like this one in order to keep from having a combinatorial-complexity explosion in the ruleset? I know what my sense of taste and proportion says. But I'm not going to impose my vision on everybody. If you have an opinion, I'd like to hear it. -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a Whether the authorities be invaders or merely local tyrants, the effect of such [gun control] laws is to place the individual at the mercy of the state, unable to resist. -- Robert Anson Heinlein, 1949 - 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] http://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Re: CML2 design philosophy heads-up
Alan Cox [EMAIL PROTECTED]: In general this is the best option, if you create a non-standard configuration for machine foo then it is your problem, not everybody else's. Which makes CML2 inferior to CML1 again. Now if it could parse CML1 rulesets this whole discussion wouldn't be needed. I think you're confusing a couple of different issues here, Alan. Even supposing CML2 could parse CML1 rulesets, the design question about how configuration *should* work (that is, what kind of user experience we want to create and who we optimize ruleset design for) wouldn't go away. I'm raising these questions now because CML2's capabilities invite thinking about them. But they're independent of the underlying language. -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a To stay young requires the unceasing cultivation of the ability to unlearn old falsehoods. -- Lazarus Long ___ kbuild-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Re: CML2 design philosophy heads-up
On Fri, May 18, 2001 at 01:22:35PM -0400, Eric S. Raymond wrote: Michael Meissner [EMAIL PROTECTED]: On Fri, May 18, 2001 at 06:09:09PM +0200, Christoph Hellwig wrote: Aunt Tillie shouldn't try to manually configure a kernel. Ummm, maybe Aunt Tillie wants to learn how to configure a kernel After all, all of us at one point in time were newbies in terms of configuring kernels, etc. And if she doesn't, maybe her teenage daughter Muffy wants to learn. You know, the one with the unicorn appliques and the pink scrunchies and the Back Street Boys posters in her bedroom? That's ok as long as she doesn't add backstreet boys songtexts as long as your signature to her mails. On the other hand she should _really_ learn how to do it - like we all did. Dammit, if we're serious about empowering people with free software we can't limit ourselves with the attitude that configuring kernels (or anything else) is the sacred preserve of a geek elite. I see _no_ reason to give up my control for people with an attitude that configuring kernels will not need knowledge of what one is doing. Your point is basically: Lets rewrite the kernel in VBA to make every word user capable of driver hacking. That doesn't work. Christoph -- Auch der Dumme hat manchmal einen gescheiten Gedanken. Er merkt es nur nicht. -- Danny Kaye ___ kbuild-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: CML2 design philosophy heads-up
Eric == Eric S Raymond [EMAIL PROTECTED] writes: Eric Jes Sorensen [EMAIL PROTECTED]: For a start, so far there has been no reason whatsoever to change the format of definitions. Eric The judgment of the kbuild team is unanimous that you are Eric mistaken on this. That's the five people (excluding me) who Eric wrote and maintained the CML1 code. *They* said that code had Eric to go, Linus has concurred with their judgment, and the argument Eric is over. Replacing the code does not require changing the style of the config files. Thats a major problem with CML2, you introduce a new 'let me do everything for you' tool that relies on a programming language that is not being shipped by any major vendor nor does it look like they are planning to do it anytime soon. And even if they start doing so, this is a totally unreasonable requirement, you *must* to make it possible to compile kernels on older distributions without requiring people to update half of their system. On some architectures, the majority of the users are still on glibc 2.0 and other old versions of tools. Telling them to install an updated gcc for kernel compilation is a necessary evil, which can easily be done without disturbing the rest of the system. Updating the system's python installation is not a reasonable request. Nobody disagrees that the Makefiles needs a redesign, however that doesn't mean everything else has to be redisigned in a totally incompatible manner. Eric If you persist in misunderstanding what I am doing, you are Eric neither going to be able to influence my behavior nor to Eric persuade other people that it is wrong. Listen carefully, Eric please: Oh I don't, on the other hand I see you consistently ignoring the needs and requirements of the users. So far I haven't heard a single developer say something positive about CML2, the most positive I have heard so far has been whatever, it's his choice, I don't care, I want to hack. The majority are of the NO! and you got to be kiddin'. Eric 1. The CML2 system neither changes the CONFIG_ symbol namespace Eric nor assumes any changes in it. (Earlier versions did, but Greg Eric Banks showed me how to avoid needing to.) Let's just say you didn't exactly give peoiple a good impression with the trolling around on how everybody had to change their option names and how important it was for the world. Eric 2. The ruleset changes I have made simplify the configuration Eric process, but they do *not* in any way restrict the space of Eric configurations that are possible. By design, every valid Eric (consistent) configuration in CML1 can be generated in CML2. I Eric treat departures from that rule as rulesfile bugs and fix them Eric (as I just did at Ray Knight's instruction). What spawned this recent discussion was you wanting to remove config options and automatically enable things instead of giving the users the explicit choice to do so. Now you are trying to tell me that you are not changing things? Eric 3. I do not have (nor do I seek) the power to impose anything Eric on anyone. We'll let that one stand on display for a few minutes. Eric You really ought to give CML2 a technical evaluation yourself Eric before you flame me again. Much of what you seem to think you Eric know is not true. So far I have had to deal with a number of requests from you trying to impose unreasonable changes on developers. Thats more than plenty for me. I do not have Python2 installed and I do not plan to, if you change CML2 to use a reasonable programming language I might give it a try. Jes PS: And if you could start making your .signature rfc1855 compliant it was be pleasant for all readers of this mailing list. ___ kbuild-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Re: CML2 design philosophy heads-up
On Fri, May 18, 2001 at 11:51:28AM -0400, John Cowan wrote: Jes Sorensen wrote: Telling them to install an updated gcc for kernel compilation is a necessary evil, which can easily be done without disturbing the rest of the system. Updating the system's python installation is not a reasonable request. Au contraire. It is very reasonable to have both python and python2 installed. Having two different gcc versions installed is a big pain in the arse. Fump. Some distributions do even come with two gcc's out of the box. With the whole egcs and gcc2.95 (dunno about 3.0) you can even share the compiler driver if you want. Christoph -- Of course it doesn't work. We've performed a software upgrade. ___ kbuild-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Re: CML2 design philosophy heads-up
On 05/18/2001 at 02:44:07 PM [EMAIL PROTECTED] wrote: But the real question is whether the old tools have enough value to be worth the effort. What problem are you trying to solve here? How about: 1. Some of us are perfectly satisfied with the existing tools and don't want them to be yanked out from under us. 2. Some of us have no interest in Python and don't like being forced to deal with installing/upgrading it just for CML2. Since someone is rewriting CML2 in C that #2 is a non issue. #1 may be a case of bolting alternative ui's onto the parser ___ kbuild-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Re: CML2 design philosophy heads-up
But the real question is whether the old tools have enough value to be worth the effort. What problem are you trying to solve here? Im just playing with ideas and writing a CML1 parser for amusement while I ponder single pass computation of the entire dependancy graph from a CML1 rule base 8) ___ kbuild-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Re: CML2 design philosophy heads-up
On Fri, May 18, 2001 at 12:34:13PM -0400, Eric S. Raymond wrote: Alan, it sounds very much like you just said something stupid. This seems sufficiently unlikely that I am shaking my head in disbelief and fingernailing wax out of both ears (and if you think doing both those things at once is easy try it sometime :-)). Do you really believe that anyone is going to maintain the CML1 tools for as long as a nanosecond after they get dropped out of the kernel tree? I _will_ continue to maintain mconfig (after mec stopped even before cml2). Christoph -- Of course it doesn't work. We've performed a software upgrade. ___ kbuild-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: CML2 design philosophy heads-up
On Fri, 18 May 2001, Eric S. Raymond wrote: Tom Rini [EMAIL PROTECTED]: SCSI emulation over IDE, CONFIG_BLK_DEV_IDESCSI. You have the SCSI mid layer code but no SCSI hardware drivers. It is a realistic case for an embedded CD-RW appliance. Or alternatively, you want to enable SCSI code, with no hardware driver, because you are going to build pcmcia, which builds the scsi drivers only if CONFIG_SCSI is defined, and the user might put in an Adaptec 1460B or 1480 scsi card into your pcmcia slot. Both of these 'problems' assume that you can have IDE or PCMCIA on these particular boxes. Does anyone know if that's actually true? The answer is: no, you can't. I found a feature list for the MVME147 on the web at http://www.mcg.mot.com/cfm/templates/article.cfm?PageID=1095. It confirmed what thought I remembered from the Motorola site; no PCMCIA, no IDE/ATAPI. As a matter of fact neither of these technologies existed yet when the board was being designed in the mid-1980s. But it is a VME board. That means you can put a SCSI controller on the VME bus (and these do exist, I have one right here). Frank (The article I found is kind of interesting. It's a dissection of the MVME147's design and history...narrated in first person.) In any case, if this *had* been a problem, the right fix IMO would have been to split the SCSI symbol into SCSI and SCSI_DRIVERS and have constraints that would make SCSI and the presence of any SCSI card imply SCSI_DRIVERS. -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a The prestige of government has undoubtedly been lowered considerably by the Prohibition law. For nothing is more destructive of respect for the government and the law of the land than passing laws which cannot be enforced. It is an open secret that the dangerous increase of crime in this country is closely connected with this. -- Albert Einstein, My First Impression of the U.S.A., 1921 - 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/ HI! I'm a .signature virus! cp me into your .signature file to help me spread! ___ kbuild-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: CML2 design philosophy heads-up
Alan Cox [EMAIL PROTECTED]: What I am trying to say is that if you can infer probable configuration categories that are relevant then instead of automatically filling the other areas in and blocking changing them without using vi you can put the other options as a submenu. That guides the less expert user and also helps rather than hinders the expert OK, that's useful input. Noted. There's a bit of a technical problem with the distinction between derivations (which are like macros) and question symbols (which can be suppressed or unsuppressed depending on their visibility predicate But perhaps I can think up a solution to that one over lunch. -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a You [should] not examine legislation in the light of the benefits it will convey if properly administered, but in the light of the wrongs it would do and the harm it would cause if improperly administered -- Lyndon Johnson, former President of the U.S. ___ kbuild-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Re: CML2 design philosophy heads-up
On 05/18/2001 at 02:44:07 PM [EMAIL PROTECTED] wrote: But the real question is whether the old tools have enough value to be worth the effort. What problem are you trying to solve here? How about: 1. Some of us are perfectly satisfied with the existing tools and don't want them to be yanked out from under us. 2. Some of us have no interest in Python and don't like being forced to deal with installing/upgrading it just for CML2. Wayne ___ kbuild-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Re: CML2 design philosophy heads-up
Alan Cox [EMAIL PROTECTED]: Being able to turn CML2 into CML1 might be the more useful exercise. That's...not a completely crazy idea. Hmmm... It might be possible to take a CML2 rulebase and generate a sort of stupid jackleg CML1 translation of it. The resulting config.in would be huge and nasty, and would only work in forward sequence with no side-effect computation, but you just might be able to get the old tools to parse it. Again there's a technical problem with derivations. Probably solvable. But the real question is whether the old tools have enough value to be worth the effort. What problem are you trying to solve here? -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a This would be the best of all possible worlds, if there were no religion in it. -- John Adams, in a letter to Thomas Jefferson. ___ kbuild-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/kbuild-devel
