Re: [kbuild-devel] Re: CML2 design philosophy heads-up
Tom Rini [EMAIL PROTECTED]: python1.5.x is compatiable w/ python2 EXCEPT in the cases where the script uses undocumented things which did work in python1.5.x. That's true of the core language. The reason I moved to 2.0 was that there are library changes in 2.0 that enabled me to to cut CML2's in-kernel footprint substantially. Which brings up another point, RedHat (7.1?) and Debian/woody both have the option of having python2 around. Anyone know about mandrake? My point is that some dists are already dealing with python2. Yes. By the time 2.5 forks, distros covering an estimated 85% of the market will carry python2 binaries which the CML2 install script will find automatically. By the time 2.6 forks, we're going to laugh if we ever remember that we thought this was an issue. Eric, would it be easy/possible to go back to requiring python 1.5.x for CML2, since that is what many dists ship with? It wouldn't be too difficult. But it would make the code heavier, and I'm not clear that it would make anybody happy who isn't already willing to deal with the design concept. -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a The world is filled with violence. Because criminals carry guns, we decent law-abiding citizens should also have guns. Otherwise they will win and the decent people will lose. -- James Earl Jones ___ kbuild-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Re: CML2 design philosophy heads-up
Brent D. Norris [EMAIL PROTECTED]: didn't Eric say that this has stalled though? Is that not the case? Nope. Greg is still working. He got the first version of the theorem prover working recently. -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a A wise and frugal government, which shall restrain men from injuring one another, which shall leave them otherwise free to regulate their own pursuits of industry and improvement, and shall not take from the mouth of labor the bread it has earned. This is the sum of good government, and all that is necessary to close the circle of our felicities. -- Thomas Jefferson, in his 1801 inaugural address ___ kbuild-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Re: CML2 design philosophy heads-up
Jakob == Jakob Østergaard [EMAIL PROTECTED] writes: Jakob On Sun, May 20, 2001 at 10:10:49PM -0400, Robert M. Love wrote: I think this is a very important point, and one I agree with. I tend to let my distribution handle stuff like python. now, I use RedHat's on-going devel, RawHide. it is not using python2. in fact, since switching to python2 may break old stuff, I don't expect python2 until 8.0. that wont be for 9 months. 90% of RedHat's configuration tools, et al, are written in python1 and they just are not going to change on someone's whim. Jakob 2.6.0 isn't going to happen for at least a year or two. What's Jakob the problem ? Jakob Want 2.5.X ? Get the tools too. Some people grab the latest devel kernels because thats all that works on their hardware. Jakob I'm in no position to push people around, but I think the Jakob whining about CML2 tool requirements is completely unjustified. Jakob If we required that everything worked with GCC 2.7.2 and nmake, Jakob where would we be today ? I'm a lot more worried about CML2 Jakob itself than about the tools it requires :) gcc-2.7.2 is broken it miscompiles the kernel, Python1 or bash are not. Jakob Whether CML2 requires python2 or not, the distributions will Jakob change. This is not about Eric pushing something down people's Jakob throats. Tools evolve, and new revisions introduce Jakob incompatibilities, but distributions still follow the Jakob evolution. Nobody ships perl4 today either. The point is that Eric has been trying to push distributions to ship P2. Jes ___ kbuild-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Re: CML2 design philosophy heads-up
On Mon, May 21, 2001 at 11:58:34AM +0200, Jes Sorensen wrote: Jakob == Jakob ?stergaard [EMAIL PROTECTED] writes: Jakob On Sun, May 20, 2001 at 10:10:49PM -0400, Robert M. Love wrote: I think this is a very important point, and one I agree with. I tend to let my distribution handle stuff like python. now, I use RedHat's on-going devel, RawHide. it is not using python2. in fact, since switching to python2 may break old stuff, I don't expect python2 until 8.0. that wont be for 9 months. 90% of RedHat's configuration tools, et al, are written in python1 and they just are not going to change on someone's whim. Jakob 2.6.0 isn't going to happen for at least a year or two. What's Jakob the problem ? Jakob Want 2.5.X ? Get the tools too. Some people grab the latest devel kernels because thats all that works on their hardware. And they can grab the latest tools too. Why is this a problem again? python1.5.x is compatiable w/ python2 EXCEPT in the cases where the script uses undocumented things which did work in python1.5.x. But that's not as big of a problem since they can co-exist. Debian already does this (And thus CML2 already deals with python2 being called 'python2') and I wouldn't be supprised if the PowerTools python2 rpm someone pointed out makes them co-exist as well. Which brings up another point, RedHat (7.1?) and Debian/woody both have the option of having python2 around. Anyone know about mandrake? My point is that some dists are already dealing with python2. Jakob I'm in no position to push people around, but I think the Jakob whining about CML2 tool requirements is completely unjustified. Jakob If we required that everything worked with GCC 2.7.2 and nmake, Jakob where would we be today ? I'm a lot more worried about CML2 Jakob itself than about the tools it requires :) gcc-2.7.2 is broken it miscompiles the kernel, Python1 or bash are not. Well no, but python1 requires another 2k lines of python code or so. Eric, would it be easy/possible to go back to requiring python 1.5.x for CML2, since that is what many dists ship with? Jakob Whether CML2 requires python2 or not, the distributions will Jakob change. This is not about Eric pushing something down people's Jakob throats. Tools evolve, and new revisions introduce Jakob incompatibilities, but distributions still follow the Jakob evolution. Nobody ships perl4 today either. The point is that Eric has been trying to push distributions to ship P2. Maybe, maybe not. Forgetting about the QA time and whatnot, there's good odds that all of the python scripts RedHat (for example) ships will just work with python2. I know one of the PPC dists didn't ship with python2 (which does have a lot of python bits to it) entirely because they were already in testing when it came out. It's not something the distros can switch to at a whim, but it's also something which shouldn't cause them problems when they do. -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ ___ kbuild-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Re: CML2 design philosophy heads-up
On 21 May 2001 02:11:39 -0400, Mike A. Harris wrote: On 20 May 2001, Robert M. Love wrote: (on another note, about the coexist issue: am i going to have a python and python2 binary? so now the config tool will find which to use, ala the kgcc mess? great) For the record, the kgcc mess you speak of was used by Conectiva, and I believe also by debian before adoption in Red Hat Linux. It was about as good a solution as one could get for the problem that it solved - the kernel being broken and unable to build with our gcc-2.96. Just to head anyone off at the pass... the kernel is fixed and now builds properly with gcc-2.96. my view of the mess wasn't the fact RedHat used kgcc. i think that was a good move. i mean how in 2.2 the Makefile must search out for gcc, kgcc, gcc-2.95, gcc-2.91 etc. what is the cml2 parser going to do? search for my python2 binary because my python1 binary is my standard python? -- Robert M. Love [EMAIL PROTECTED] [EMAIL PROTECTED] ___ kbuild-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Re: CML2 design philosophy heads-up
#2 is fixed by rewriting tools in C didn't Eric say that this has stalled though? Is that not the case? Brent Norris Executive Advisor -- WKU-Linux System Administrator -- WKU-Center for Biodiversity Best Mechanical ___ kbuild-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Re: CML2 design philosophy heads-up
On Sun, May 20, 2001 at 10:10:49PM -0400, Robert M. Love wrote:
On 21 May 2001 02:29:17 +0200, Jes Sorensen wrote:
John Au contraire. It is very reasonable to have both python and
John python2 installed. Having two different gcc versions installed
John is a big pain in the arse.
It's not unreasonable to have both installed, it's unreasonable to
require it.
Eric seems to think he can tell every distributor to ship Python2
tomorrow. Well it's a fine dream but it's not going to happen; snip
I think this is a very important point, and one I agree with. I tend to
let my distribution handle stuff like python. now, I use RedHat's
on-going devel, RawHide. it is not using python2. in fact, since
switching to python2 may break old stuff, I don't expect python2 until
8.0. that wont be for 9 months. 90% of RedHat's configuration tools, et
al, are written in python1 and they just are not going to change on
someone's whim.
2.6.0 isn't going to happen for at least a year or two. What's the problem ?
Want 2.5.X ? Get the tools too.
I'm in no position to push people around, but I think the whining about CML2
tool requirements is completely unjustified. If we required that everything
worked with GCC 2.7.2 and nmake, where would we be today ? I'm a lot more
worried about CML2 itself than about the tools it requires :)
im not installing python2 from source just so i can run some new config
utility.
python2 will be in rawhide when 2.5 development requires it, if I'm not much
mistaken.
Whether CML2 requires python2 or not, the distributions will change. This is
not about Eric pushing something down people's throats. Tools evolve, and new
revisions introduce incompatibilities, but distributions still follow the
evolution. Nobody ships perl4 today either.
--
: [EMAIL PROTECTED] : And I see the elder races, :
:.: putrid forms of man:
: Jakob Østergaard : See him rise and claim the earth, :
:OZ9ABN : his downfall is at hand. :
:.:{Konkhra}...:
___
kbuild-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Re: CML2 design philosophy heads-up
On Mon, 21 May 2001, Jakob Østergaard wrote: On Sun, May 20, 2001 at 10:10:49PM -0400, Robert M. Love wrote: im not installing python2 from source just so i can run some new config utility. python2 will be in rawhide when 2.5 development requires it, if I'm not much mistaken. Alan said someone is rewriting in C, so the python2 requirement is already becoming a non-problem. -Mike (don't like requirement, but don't think it's a big hairy deal either) ___ kbuild-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Re: CML2 design philosophy heads-up
On 21 May 2001, Jes Sorensen wrote: John Au contraire. It is very reasonable to have both python and John python2 installed. Having two different gcc versions installed John is a big pain in the arse. It's not unreasonable to have both installed, it's unreasonable to require it. Eric seems to think he can tell every distributor to ship Python2 tomorrow. Well it's a fine dream but it's not going to happen Distributors aren't going to ship Linux 2.5.x tomorrow either. Nicolas ___ kbuild-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Re: CML2 design philosophy heads-up
On 21 May 2001 02:29:17 +0200, Jes Sorensen wrote: John Au contraire. It is very reasonable to have both python and John python2 installed. Having two different gcc versions installed John is a big pain in the arse. It's not unreasonable to have both installed, it's unreasonable to require it. Eric seems to think he can tell every distributor to ship Python2 tomorrow. Well it's a fine dream but it's not going to happen; snip I think this is a very important point, and one I agree with. I tend to let my distribution handle stuff like python. now, I use RedHat's on-going devel, RawHide. it is not using python2. in fact, since switching to python2 may break old stuff, I don't expect python2 until 8.0. that wont be for 9 months. 90% of RedHat's configuration tools, et al, are written in python1 and they just are not going to change on someone's whim. im not installing python2 from source just so i can run some new config utility. (on another note, about the coexist issue: am i going to have a python and python2 binary? so now the config tool will find which to use, ala the kgcc mess? great) -- Robert M. Love [EMAIL PROTECTED] [EMAIL PROTECTED] ___ kbuild-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Re: CML2 design philosophy heads-up
John == John Cowan [EMAIL PROTECTED] writes: John 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. John Au contraire. It is very reasonable to have both python and John python2 installed. Having two different gcc versions installed John is a big pain in the arse. It's not unreasonable to have both installed, it's unreasonable to require it. Eric seems to think he can tell every distributor to ship Python2 tomorrow. Well it's a fine dream but it's not going to happen; Most distributors do not ship new major versions of tools in their minor number release versions. I've seen him mention the number 6 months until everybody ships it, but a) thats not going to happen Red Hat is currently at 7.1 (if one looks at their release history, one would say there is a good chance there will be a 7.2) not to mention the release rate of Debian (not sure about the current state of all other distributions). 18 months is more realistic for it to be deployed widely enough. 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'. John Anonymized hearsay evidence is less than convincing. Well I don't like to quote personal conversations without peoples' approval, now both David Woodhouse and Arjan are two examples. Jes ___ 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
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
[kbuild-devel] Re: CML2 design philosophy heads-up
On Thu, May 17, 2001 at 05:47:41PM +1000, Keith Owens wrote: On Thu, 17 May 2001 03:26:36 -0400, Eric S. Raymond [EMAIL PROTECTED] wrote: Pavel Machek [EMAIL PROTECTED]: And If I want scsi-on-atapi emulation but not vme147_scsi? Help me understand this case, please. What is scsi-on-atapi? Is SCSI on when you enable it? And is it a realistic case for an SBC? 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. -- Michael Meissner, Red Hat, Inc. (GCC group) PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA Work: [EMAIL PROTECTED] phone: +1 978-486-9304 Non-work: [EMAIL PROTECTED] fax: +1 978-692-4482 ___ kbuild-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: CML2 design philosophy heads-up
Pavel Machek [EMAIL PROTECTED]: And If I want scsi-on-atapi emulation but not vme147_scsi? Help me understand this case, please. What is scsi-on-atapi? Is SCSI on when you enable it? And is it a realistic case for an SBC? The CML2 constraint language is very flexible. I can make it do the right thing, if I know what the right thing is. -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a Where rights secured by the Constitution are involved, there can be no rule making or legislation which would abrogate them. -- Miranda vs. Arizona, 384 US 436 p. 491 ___ kbuild-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: CML2 design philosophy heads-up
On Thu, May 17, 2001 at 05:35:49AM -0400, Michael Meissner wrote: On Thu, May 17, 2001 at 05:47:41PM +1000, Keith Owens wrote: On Thu, 17 May 2001 03:26:36 -0400, Eric S. Raymond [EMAIL PROTECTED] wrote: Pavel Machek [EMAIL PROTECTED]: And If I want scsi-on-atapi emulation but not vme147_scsi? Help me understand this case, please. What is scsi-on-atapi? Is SCSI on when you enable it? And is it a realistic case for an SBC? 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? What eric is trying to do, can work, if done very carefully, and in very limited cases as well. -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ ___ kbuild-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: CML2 design philosophy heads-up
Jes Sorensen [EMAIL PROTECTED]: If Ray wants to fix things, it's just fine with me. I have corrected the Mac dependencies as Ray directed. Eric Does this mean you'll take over maintaining the CML2 rules files Eric for the m68k port, so I don't have to? That would be wonderful. For a start, so far there has been no reason whatsoever to change the format of definitions. The judgment of the kbuild team is unanimous that you are mistaken on this. That's the five people (excluding me) who wrote and maintained the CML1 code. *They* said that code had to go, Linus has concurred with their judgment, and the argument is over. So far you have only been irritating developers for no reason. What I asked you to do is to NOT change whatever config options developers developers felt were necessary to introduce. If you want to change the format of the config.in files go ahead. Messing around with the config options themselves is *not* for you to do, nor are you to impose a more restrictive space for people to work in. If you persist in misunderstanding what I am doing, you are neither going to be able to influence my behavior nor to persuade other people that it is wrong. Listen carefully, please: 1. The CML2 system neither changes the CONFIG_ symbol namespace nor assumes any changes in it. (Earlier versions did, but Greg Banks showed me how to avoid needing to.) 2. The ruleset changes I have made simplify the configuration process, but they do *not* in any way restrict the space of configurations that are possible. By design, every valid (consistent) configuration in CML1 can be generated in CML2. I treat departures from that rule as rulesfile bugs and fix them (as I just did at Ray Knight's instruction). 3. I do not have (nor do I seek) the power to impose anything on anyone. You really ought to give CML2 a technical evaluation yourself before you flame me again. Much of what you seem to think you know is not true. -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a According to the National Crime Survey administered by the Bureau of the Census and the National Institute of Justice, it was found that only 12 percent of those who use a gun to resist assault are injured, as are 17 percent of those who use a gun to resist robbery. These percentages are 27 and 25 percent, respectively, if they passively comply with the felon's demands. Three times as many were injured if they used other means of resistance. -- G. Kleck, Policy Lessons from Recent Gun Control Research, ___ 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 I've said before on these lists that one of the purposes of Eric CML2's single-apex tree design is to move the configuration Eric dialog away from low-level platform- specific questions towards Eric higher-level questions about policy or intentions. Eric Or to put another way: away from hardware, towards capabilities. Eric As a concrete example, the CML2 rulesfile master for the m68k Eric port tree now has a section that looks like this: Eric # These were separate questions in CML1. They enable on-board Eric peripheral # controllers in single-board computers. derive Eric MVME147_NET from MVME147 NET_ETHERNET derive MVME147_SCC from Eric MVME147 SERIAL derive MVME147_SCSI from MVME147 SCSI derive Eric MVME16x_NET from MVME16x NET_ETHERNET derive MVME16x_SCC from Eric MVME16x SERIAL derive MVME16x_SCSI from MVME16x SCSI derive Eric BVME6000_NET from BVME6000 NET_ETHERNET derive BVME6000_SCC Eric from BVME6000 SERIAL derive BVME6000_SCSI from BVME6000 SCSI Not all cards have all features, not all users wants to enable all features. Eric # These were separate questions in CML1 derive MAC_SCC from MAC Eric SERIAL derive MAC_SCSI from MAC SCSI derive SUN3_SCSI from Eric (SUN3 | SUN3X) SCSI As Alan already pointed out thats assumption is invalid. Eric This is different from the CML1 approach, which generally Eric involved explicitly specifying each driver with mutual Eric dependencies described (if at all) in Configure.help. Yes and it should stay like that. If Richard had wanted all those features enabled per default when an MVME setting was selected, he would have done it in the config.in file, which is perfectly valid to do so today. Eric This note is a heads-up. If others with a stake in the Eric configuration system (port managers, etc.) have objections to Eric moving further in this direction, I need to hear about it, and Eric about what you think we should be doing instead. -- a Eric href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a Yes I have objections. I thought I had made this clear a long time ago: Go play with another port and leave the m68k port alone. Thank you Jes ___ kbuild-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: CML2 design philosophy heads-up
Jes Sorensen [EMAIL PROTECTED]: Not all cards have all features, not all users wants to enable all features. Yes, I understand that. You're not reading the derivations correctly. Let's take an example: derive MVME147_SCSI from MVME147 SCSI This doesn't turn on MVME147_SCSI on every MVME147 board. It turns on MVME147_SCSI when both MVME147 *and SCCI* are on. So to suppress MVME147_SCSI, one just leaves SCCI off. All these derived symbols will still be controllable. The difference is that instead of being controlled by a low-level hardware-oriented question they're controlled by a capability or subsystem symbol like SCSI, NET_ETHERNET, or SERIAL. Eric # These were separate questions in CML1 derive MAC_SCC from MAC Eric SERIAL derive MAC_SCSI from MAC SCSI derive SUN3_SCSI from Eric (SUN3 | SUN3X) SCSI As Alan already pointed out thats assumption is invalid. I'm in touch with Ray Knight directly and will fix this as he requests. Yes I have objections. I thought I had made this clear a long time ago: Go play with another port and leave the m68k port alone. Does this mean you'll take over maintaining the CML2 rules files for the m68k port, so I don't have to? That would be wonderful. Reasoned objections can change my behavior. Grunting territorial challenges at me will not. You have two options: (1) persuade Linus that the whole CML2 thing is a bad idea and should be dropped, or (2) work with me to correct any errors I have made and improve the system. Growling at me and hoping I go away won't work, not when I've invested a year's effort in this project. -- 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
[kbuild-devel] Re: CML2 design philosophy heads-up
On Mon, May 07, 2001 at 09:56:18PM -0400, Eric S. Raymond wrote: Tom Rini [EMAIL PROTECTED]: Only sort-of. There are some cases where you can get away with that. Probably. eg If you ask for PARPORT, on x86 that means yes to PARPORT_PC, always (right?) Yes. So the right answer there isn't to use a derivation but to say: require X86 and PARPORT implies PARPORT_PC unless X86==n suppress PARPORT_PC which forces PARPORT_PC==y and makes the question invisible on X86 machines, but leaves the question visible on all others. Yes, but there are quite a lot of people who don't want parport/serial/whatever compiled into their kernels at all, eventhough they have an x86. Think low-memory systems or similar. /David _ _ // David Weinehall [EMAIL PROTECTED] / Northern lights wander \\ // Project MCA Linux hacker// Dance across the winter sky // \ http://www.acc.umu.se/~tao// Full colour fire / ___ kbuild-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: CML2 design philosophy heads-up
David Weinehall [EMAIL PROTECTED]: require X86 and PARPORT implies PARPORT_PC unless X86==n suppress PARPORT_PC which forces PARPORT_PC==y and makes the question invisible on X86 machines, but leaves the question visible on all others. Yes, but there are quite a lot of people who don't want parport/serial/whatever compiled into their kernels at all, eventhough they have an x86. Think low-memory systems or similar. That's OK. Neither of these constraints says PARPORT must be compiled in. Look at the conditionals carefully. -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a ...The Bill of Rights is a literal and absolute document. The First Amendment doesn't say you have a right to speak out unless the government has a 'compelling interest' in censoring the Internet. The Second Amendment doesn't say you have the right to keep and bear arms until some madman plants a bomb. The Fourth Amendment doesn't say you have the right to be secure from search and seizure unless some FBI agent thinks you fit the profile of a terrorist. The government has no right to interfere with any of these freedoms under any circumstances. -- Harry Browne, 1996 USA presidential candidate, Libertarian Party ___ kbuild-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: CML2 design philosophy heads-up
Alan Cox [EMAIL PROTECTED]: There are also a lot of config options that are implied by your setup in an embedded enviromment but which you dont actually want because you didnt wire them Well, then, you don't specify the guard capability! If your MV147 isn't wired for serial, then leave SERIAL off. The point of the derivation is exactly to let you do that. -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a Sometimes the law defends plunder and participates in it. Sometimes the law places the whole apparatus of judges, police, prisons and gendarmes at the service of the plunderers, and treats the victim -- when he defends himself -- as a criminal. -- Frederic Bastiat, The Law ___ kbuild-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: CML2 design philosophy heads-up
Jamie Lokier [EMAIL PROTECTED]: Which is unfortunately wrong if you want the parport subsystem on x86 but won't be using the parport_pc driver with it. I.e. you'll be using some other driver which isn't part of the kernel tree. Perhaps a modified version of parport_pc, perhaps something else. If you're integrating drivers that aren't in the kernel tree, you can and should patch the CML2 rulebase to compensate. So your patch for the modified driver should comment out the PARPORT_PC==PARPORT requirement. Problem solved. More generally, arguments of the form Non-mainline custom hack X could invalidate constraint Y, therefore we can't have Y in the rulebase are dangerous -- I suspect you could reduce your set of constraints to nil very quickly that way, and thus badly screw over the 99% of people who just want to build a more or less stock kernel. -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a The abortion rights and gun control debates are twin aspects of a deeper question --- does an individual ever have the right to make decisions that are literally life-or-death? And if not the individual, who does? ___ kbuild-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: CML2 design philosophy heads-up
Eric S. Raymond wrote: More generally, arguments of the form Non-mainline custom hack X could invalidate constraint Y, therefore we can't have Y in the rulebase are dangerous -- I suspect you could reduce your set of constraints to nil very quickly that way, and thus badly screw over the 99% of people who just want to build a more or less stock kernel. Eric, Still being able to use the tool is useful! So I want a don't mess with me mode where I'd get more control than 99% of the lusers Roger. -- ** [EMAIL PROTECTED] ** http://www.BitWizard.nl/ ** +31-15-2137555 ** *-- BitWizard writes Linux device drivers for any device you may have! --* * There are old pilots, and there are bold pilots. * There are also old, bald pilots. ___ kbuild-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: CML2 design philosophy heads-up
On Mon, May 07, 2001 at 09:31:40PM -0400, Eric S. Raymond wrote: Tom Rini [EMAIL PROTECTED]: [snip] Exactly. In fact we can be more specific -- the Macintoshes in question are the old-fashioned NuBus-based 68k toaster boxes, not the more recent designs with a PCI bus. Relevant stuff in the Configure.help implies that MAC_SCC and MAC_SCSI enable support for the on-board hardware built into those puppies. But Alan's point is a good one. There are _lots_ of cases you can't get away with things like this, unless you get very fine grained. In fact, it would be much eaiser to do this seperately from the kernel. Ie another, possibly/probably _not_ inkernel config tool which asks what machine you have, picks lots of sane defaults and setups a kernel config for you. This is _sort of_ what PPC does right now with the large number of 'default configs' (arch/ppc/configs). You're really talking about a different issue here, autoconfiguration rather than static dependencies. Giacomo Catenazzi is working on that. Only sort-of. There are some cases where you can get away with that. Probably. eg If you ask for PARPORT, on x86 that means yes to PARPORT_PC, always (right?) On other arches (someone brought this up before) it could be PC, it could be something else. My point is there are only some cases where you can get away with asking for serial and knowing the driver. I've given this some thought before, and at least on PPC, you can at best segment off some drivers as depending on family X, but family X doesn't mean you have part Y. The other thing to keep in mind is I'm sure there's lots of unintentionally correct bits. In short, please be very careful when you change a symbol from a question to a derive. You're bound to piss off someone :) -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ ___ kbuild-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: CML2 design philosophy heads-up
Tom Rini [EMAIL PROTECTED]: Only sort-of. There are some cases where you can get away with that. Probably. eg If you ask for PARPORT, on x86 that means yes to PARPORT_PC, always (right?) Yes. So the right answer there isn't to use a derivation but to say: require X86 and PARPORT implies PARPORT_PC unless X86==n suppress PARPORT_PC which forces PARPORT_PC==y and makes the question invisible on X86 machines, but leaves the question visible on all others. -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a The real point of audits is to instill fear, not to extract revenue; the IRS aims at winning through intimidation and (thereby) getting maximum voluntary compliance -- Paul Strassel, former IRS Headquarters Agent Wall St. Journal 1980 ___ kbuild-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/kbuild-devel
