Re: [kbuild-devel] Your opinion on CML2 and kbuild-2.5
Personal I would like to see kbuild-2.5 included ASAP. Among other stuff I like the compressed output during compilation. So do I. I like the clean design of kbuild-2.5 and i'm more than fine with the overall speed. I vote for inclusion in 2.5. As small as my vote can be considered... Thomas ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Your opinion on CML2 and kbuild-2.5
On Fri, Feb 15, 2002 at 11:22:00AM +0100, Giacomo Catenazzi wrote: Eric S. Raymond wrote: 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. [snip] CML2: [snip] The big problem in CML2 is python (and python2). This is a red herring. People bitch and moan about it, but it's not a problem. The real problem with CML2 is 'enhancements' that come with the package. The first round of CML2 that goes into the kernel needs to match the current set, bug/feature for bug/feature, and counter intuitive to normal user question for coutner intuituve to normal user question. 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). -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ ___ 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]: 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
On Fri, Feb 15, 2002 at 10:51:18AM -0500, Eric S. Raymond wrote: 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. I could have sworn I told you not to make it a derivation when you suggested to do that (around the time of asking you to make CONFIG_RTC tell users not to enable it on PPC, since they probably want CONFIG_PPC_RTC). It's still not right in 2.3.0 since it's a derivation, when it's an either/or question (drivers/char/rtc.c does work on some machines, and not others). But you also seem to be ignoring my point about CML2 adding in new features/enhancements at once instead of being a replacement and then patches to add new features which (have been|need to be) discussed more. -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Your opinion on CML2 and kbuild-2.5
On Friday 15 February 2002 09:04, Tom Rini wrote: On Fri, Feb 15, 2002 at 11:22:00AM +0100, Giacomo Catenazzi wrote: [much sippage] The big problem in CML2 is python (and python2). This is a red herring. People bitch and moan about it, but it's not a problem. Agreed, but it is a minor irritation for me, and could be a major irritation for others. On my RH 7.2 system, the lpd startup scripts don't work with anything but Python 1.5.2, so I have to switch things around a little if I want to get lpd working. This is very easy to do, and I don't have this problem on Mandrake which is fully compatible with Python 2. The real problem with CML2 is 'enhancements' that come with the package. The first round of CML2 that goes into the kernel needs to match the current set, bug/feature for bug/feature, and counter intuitive to normal user question for coutner intuituve to normal user question. This is an extremely important point. When applications such as make xconfig and make menuconfig have been around a long time, a set of users will exist who will STRONGLY resist any change to the look and feel and operation of the interfaces to those programs. My own experience underscores this. I ported an old graphics applications program written for a VAX and a techtronics monochrome display to a Unix/X-window system. The port made use of color, and other features of X. But, oddly enough, very oddly enough, the users _demanded_ that the ported application have a Classic mode which had exactly the same look and feel as the old system which they had used for years. So, I went back and coded some more and everyone was happy. The new users used the new interface, while the fuddy-duddies continued to use the old Classic mode for a few years. So, having a make xconfig which has a classic mode which emulates as closely as possible the look and feel of the current system could be a good selling point. Steven ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Your opinion on CML2 and kbuild-2.5
On Fri, Feb 15, 2002 at 09:33:01AM -0700, Steven Cole wrote: On Friday 15 February 2002 09:04, Tom Rini wrote: On Fri, Feb 15, 2002 at 11:22:00AM +0100, Giacomo Catenazzi wrote: [much sippage] The big problem in CML2 is python (and python2). This is a red herring. People bitch and moan about it, but it's not a problem. Agreed, but it is a minor irritation for me, and could be a major irritation for others. On my RH 7.2 system, the lpd startup scripts don't work with anything but Python 1.5.2, so I have to switch things around a little if I want to get lpd working. This is very easy to do, and I don't have this problem on Mandrake which is fully compatible with Python 2. It's possible to have python 2.x be 'python2'. The real problem with CML2 is 'enhancements' that come with the package. The first round of CML2 that goes into the kernel needs to match the current set, bug/feature for bug/feature, and counter intuitive to normal user question for coutner intuituve to normal user question. This is an extremely important point. When applications such as make xconfig and make menuconfig have been around a long time, a set of users will exist who will STRONGLY resist any change to the look and feel and operation of the interfaces to those programs. It's not so much the look feel (which seems to have been copied well by now), but policy changes. -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ ___ 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
Re: [kbuild-devel] Your opinion on CML2 and kbuild-2.5
Good day, all, On Fri, 15 Feb 2002, Eric S. Raymond wrote: Tom Rini [EMAIL PROTECTED]: Perhaps that wasn't quite the right words. Statement for Statement and no additional restrictions on questions. Statement for statement is not going to happen, simply because the structure of the old and new languages is different. 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? In Eric's defense, I added a number of those rules after looking through source code, help text and web sites for information on which busses a particular device could possibly be used. If there are mistakes in these, they're mine and not Eric's. I'd be glad to fix any mistakes that show up and Eric has been good about merging the fixes. My goal was to allow User-Mode Linux to declare that it had no physical busses at all and have all hardware devices disappear; at the time that I did the work, that goal was realized. Cheers, - Bill --- I give up, how DO you keep a mathematician busy for 350 years? -- Pierre de Fermat's friend (Courtesy of Tim Connors [EMAIL PROTECTED]) -- William Stearns ([EMAIL PROTECTED]). Mason, Buildkernel, named2hosts, and ipfwadm2ipchains are at:http://www.pobox.com/~wstearns LinuxMonth; articles for Linux Enthusiasts! http://www.linuxmonth.com -- ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Your opinion on CML2 and kbuild-2.5
On Fri, Feb 15, 2002 at 11:22:00AM +0100, Giacomo Catenazzi wrote: [Not a single word about the battle ongoing at LKLM...] kbuild-2.5: It does the right things! And this should be enought to tell you that it should be included in the next kernels. When Keith brought up the inclusion of kbuild-2.5 last time the general statement was that kbuild-2.5 had one fundamental error - speed. I have tested it a while back, and my result was not as bad as the roumours said about kbuild-2.5. Light .config, Pentium 266 with 64 MB RAM. kbuild-2.4 make dep + make bzImage ~55 minutes kbuild-2.5 make installable~60 minutes Then I added one more driver. kbuild-2.4 make dep + make bzImage ~7 minutes kbuild-2.5 make installable~2 minutes So my conclusion was that one single change where *I* had to run make dep made it worthwhile to shift to kbuild-2.5. I know that *I* have to run make dep far more often than all the kernel hackes - they know what they are doing in contrast. With respect to kbuild-2.5 inclusion, I would vote for the distributed configuration scheme that Linus et al. suggested a while ago. [driver.conf that included makefile.in, configure.help etc.] When kbuild-2.5 has been extended to support it, and the link-order have been solved then it is due time for inclusion. Jeff Garzik Keith O. had some discussion about the link-order problem a while ago, but at that point in time Keith stopped the discussion whith the statement that he did not care about 2.5, with reference to the refusual from Linus to accept among others the LINK_FIRST - LINK_LAST patch. I dunno what the conclusion on the link-order issue was. What I read between the lines is that kbuild-2.5 should not only fix the kbuild-2.4 bugs[*], but should also address the scalability issues that Linus raised - before he accepts it. [*] Bugs that I see, but kernel hackers are not hit by - because they know what they are doing. Personal I would like to see kbuild-2.5 included ASAP. Among other stuff I like the compressed output during compilation. Sam ___ 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
