[kbuild-devel] Re: CML2-2.1.3 is available
"Eric S. Raymond" <[EMAIL PROTECTED]> said: > Horst von Brand <[EMAIL PROTECTED]>: > > > Release 2.1.3: Tue Jan 15 14:41:45 EST 2002 > > > * Resync with 2.4.18-pre3 and 2.5.2. > > > * It is now possible to declare explicit saveability predicates. > > > * The `vitality' flag is gone from the language. Instead, the > > > autoprober detects the type of your root filesystem and forces > > > its symbol to Y. > > > > Great! Now I can't configure a kernel for ext3 only on an ext2 box. Keep it > > up! As it goes, we can safely forget about CML2... > > Oh, nonsense. You can do this just fine with any of the manual > configurators. Whatever happened to "Do exactly as CML1 does; leave fixes and extensions for later"? If you put the kitchen sink into it, it _won't_ go into the standard kernel. > Now repeat after me, Horst: > > The autoconfigurator is *optional*, not required. It isn't "optional", it is builtin. It doesn't matter if somebody uses it or nobody does, it will be there. And AFAIU what you have said, you are modifiying CML2 (or at least the rulebase) for the sake of it. This is _not_ what had been agreed on the matter. -- Horst von Brand http://counter.li.org # 22616 ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: CML2-2.1.3 is available
"Eric S. Raymond" <[EMAIL PROTECTED]> said: > The latest version is always available at <http://www.tuxedo.org/~esr/cml2/>. > > Release 2.1.3: Tue Jan 15 14:41:45 EST 2002 > * Resync with 2.4.18-pre3 and 2.5.2. > * It is now possible to declare explicit saveability predicates. > * The `vitality' flag is gone from the language. Instead, the > autoprober detects the type of your root filesystem and forces > its symbol to Y. Great! Now I can't configure a kernel for ext3 only on an ext2 box. Keep it up! As it goes, we can safely forget about CML2... -- Horst von Brand http://counter.li.org # 22616 ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Re: State of the new config & build system
Christoph Hellwig <[EMAIL PROTECTED]> said: > On Fri, Dec 28, 2001 at 03:39:02PM -0500, Eric S. Raymond wrote: > > It may be that the reason our experiences have been different is > > because we focus on different target languages. But I think my > > experience is an existence proof that there *is* demand for > > localization and that meeting it can have useful results. > Is your native language something different thæn english or Al's? > > Localization for technical messages sucks. badly. > Just take a look at a european computer magazine, you will find lots of > english words in the text because there is no german/frensh/whatever > one. Trying to use different grammar doesn't help the understanding. It is even worse when they try to "translate" the terms. In Spanish, the official language calls a computer "ordenador" (sorting device), and a file "fichero" (filing cabinet). It doesn't help in the least at understanding the _English_ documentation/source/... Add to it that here in South America they usually take over the English terms, using "computador" (computing device) and "archivo" (file). So it can even make it hard to understand the technical literature in your own language... My standard advise is to learn English, if nothing else for uniformity's sake. You'll need it anyway before long in anything related to computing. And it is quite useful in other areas... -- Horst von Brand [EMAIL PROTECTED] Casilla 9G, Vin~a del Mar, Chile +56 32 672616 ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: State of the new config & build system
Alan Cox <[EMAIL PROTECTED]> said:
> Something like:
>
> find $TOPDIR -name "*.cf" -exec cat {} \; > Configure.help
Make that:
cat `find $TOPDIR -name "*.cf"` > Configure.help #;-)
--
Horst von Brand [EMAIL PROTECTED]
Casilla 9G, Vin~a del Mar, Chile +56 32 672616
___
kbuild-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5
John Cowan <[EMAIL PROTECTED]> dijo: [...] > You only need to learn Python if you are going to change the > CML2 compiler or interpreter, not if you are just changing > CML2. I did look around in CML1 when I had some troubles way back. Turned out to be my fault, or was fixed in the next patch, so I didn't contribute back. Trouble is that another opaque tool makes hacking _harder_, and this in turn turns hackers away, and the development suffers. > You might as well complain that you must learn > Python to hack GNU Mailman. Just use majordomo ;-) > CML2 hacking requires knowing Python; kernel hacking does not. CML2 hacking _is_ kernel hacking, if you like to call it such or not. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, ChileFax: +56 32 797513 ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5
John Stoffel <[EMAIL PROTECTED]> said: > > "Alan" == Alan Cox <[EMAIL PROTECTED]> writes: > > >> So has anyone had time to test the Python version 1.5 based CML2 that > >> was posted? Would that make it more acceptable? > > Alan> For 2.5 its a great leap forward. > > That was my thought when I saw the patch to make CML2 work with Python > 1.5 in Kernel 2.5. I just shudder when thinking that I'll have to learn yet another weird language to be able to hack on Linux... C, gcc-isms with asm() and all, a bit of CML1, now CML2, are OK; and now Python... -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, ChileFax: +56 32 797513 ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: Requirement of make oldconfig [was: Re: [kbuild-devel] Re: CML2 1.3.1, aka ...]
John Stoffel <[EMAIL PROTECTED]> said: [...] > No, we're just asking you to make the CML2 parser more tolerant of old > and possibly broken configs. It is _much_ easier on everybody involved to just bail out and ask the user (once!) to rebuild the configuration from scratch starting from the defaults. If you support broken configurations in any way, your program is just wildly guessing what they did mean. The exact (and very probably not in any way cleanly thought out) behaviour in corner cases then becomes "the way things work", and we end up in an unmaintainable mess yet again. Please don't. -- Dr. Horst H. von Brand mailto:[EMAIL PROTECTED] Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, ChileFax: +56 32 797513 ___ kbuild-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: Requirement of make oldconfig [was: Re: [kbuild-devel] Re: CML2 1.3.1, aka ...]
Alan Cox <[EMAIL PROTECTED]> said: > In-Reply-To: <[EMAIL PROTECTED]> from "Horst von > *** Brand" at May 03, 2001 08:32:07 AM > > > No, we're just asking you to make the CML2 parser more tolerant of old > > > and possibly broken configs. > > It is _much_ easier on everybody involved to just bail out and ask the > > user (once!) to rebuild the configuration from scratch starting from > > the defaults. > No. Every new kernel changes the constraints so every new kernel you have > to reconfigure from scratch. That also makes it very hard to be sure you got > the results right. Really? I've mostly seen symbols added, very rarely did I see constraints changed. But that might be just my narrow view on the matter... > oldconfig has a simple algorithm that works well for current cases > > Start at the top of the symbols in file order. If a symbol is new ask the > user. If a symbol is now violating a constraint it gets set according to > existing constraints if not it gets set to its old value. I understand that to mean: "If it is new and (at least somewhat) unconstrained, ask the user. If fully constrained, take that value unconditionally." This is a _very_ different case from a broken configuration as a starting point, in which constraints are violated with the values as set. Hell, I had to rebuild my .config files from scratch a few times already because of wild changes in the hardware on which the resulting kernels would have to run, its not _that_ big a deal to have to perhaps have to do it once each time a new stable kernel series starts or so. People, remember that doing certain things in software is just not worth the effort. -- Dr. Horst H. von Brand mailto:[EMAIL PROTECTED] Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, ChileFax: +56 32 797513 ___ kbuild-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: Request for comment -- a better attribution system
"Eric S. Raymond" <[EMAIL PROTECTED]> said: > Alexander Viro <[EMAIL PROTECTED]>: > > Eric, it would save everyone a lot of time if you actually cared to > > pull your head out of your... theoretical constructions and spent > > some efforts figuring out how the things really work. > > I've had my nose rubbed in how things really work. That's why I want to > fix the things that are broken about how things really work. Then explain to everybody here in a language they'll understand _what_ is wrong and _why_. Then propose a solution. I for one am not convinced you have a "what", let alone a "why". And AFAIKS your solution will be an enormous burden to maintain if it is not to rot away in a very short time. -- Horst von Brand [EMAIL PROTECTED] Casilla 9G, Vin~a del Mar, Chile +56 32 672616 ___ kbuild-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: Request for comment -- a better attribution system
"Eric S. Raymond" <[EMAIL PROTECTED]> said: > This is a proposal for an attribution metadata system in the Linux kernel > sources. The goal of the system is to make it easy for people reading > any given piece of code to identify the responsible maintainer. The > motivation for this proposal is that the present system, a single > top-level MAINTAINERS file, doesn't seem to be scaling well. It has been my observation that human organizations over time grow mechanisms for doing the routine (i.e., frequent) tasks quite efficiently, while sporadic tasks are usually handled in ad hoc, case by case ways, which can be very inefficient (and usually frustrating to the would-be user). In our case, the whole kernel development system is quite adept at soaking up point patches (the bread-and-butter in LKM), while larger scope changes (like the one you are proposing, and also some cleanup patch I proposed a long while back, and the other scattered changes I've seen fly by) are very infrequent and so not handled at all well. Question is, is it really worth it to create specialized tools for this very rare case? I suspect they would cost an enormous effort to create, and will rot away before use. The observation by Alan that an applied (and even a only proposed) patch will make somebody squeal if it steps on their toes is perhaps the best tool for finding interested parties we can hope for in a widely distributed, informal, and moreover ever changing development organization. The MAINTAINERS file itself (maintainace of which is _much_ less work than what you propose) is (by your own account IIRC) incomplete and out of date. -- Horst von Brand [EMAIL PROTECTED] Casilla 9G, Vin~a del Mar, Chile +56 32 672616 ___ kbuild-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Request for comment -- a better attribution system
"Giacomo A. Catenazzi" <[EMAIL PROTECTED]> said: [...] > It whould nice also if we include the type of the license (GPL,...). If it's in-kernel, it is GPLed. -- Horst von Brand [EMAIL PROTECTED] Casilla 9G, Vin~a del Mar, Chile +56 32 672616 ___ kbuild-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: Request for comment -- a better attribution system
"Eric S. Raymond" <[EMAIL PROTECTED]> said: > Subject: Re: Request for comment -- a better attribution system > > Return-Path: [EMAIL PROTECTED] > Delivery-Date: Sat Apr 21 20:28:52 2001 > Return-Path: <[EMAIL PROTECTED]> > Reply-To: [EMAIL PROTECTED] > Mail-Followup-To: "Eric S. Raymond" <[EMAIL PROTECTED]>, >"Albert D. Cahalan" <[EMAIL PROTECTED]>, >CML2 <[EMAIL PROTECTED]>, >[EMAIL PROTECTED] > References: <[EMAIL PROTECTED]> <200104212023.f3LKN7P188973@sat > ***urn.cs.uml.edu> > Mime-Version: 1.0 > Content-Disposition: inline > User-Agent: Mutt/1.2.5i > In-Reply-To: <[EMAIL PROTECTED]>; from [EMAIL PROTECTED] > ***ml.edu on Sat, Apr 21, 2001 at 04:23:06PM -0400 > Organization: Eric Conspiracy Secret Labs > X-Eric-Conspiracy: There is no conspiracy > Sender: [EMAIL PROTECTED] > Precedence: bulk > X-Mailing-List: [EMAIL PROTECTED] > > Albert D. Cahalan <[EMAIL PROTECTED]>: [...] > > It is nice to have a single file for grep. With the proposed > > changes one would sometimes need to grep every file. > The right way to handle that is to have a report generator that does the > grep for you, or if you like simply returns the concatenation of all the > map blocks so you can grep that. Please, _no_ specialized-just-for-linux-kernel-hacking tools! Unix is great because it has _no_ such for-one-task-only tools, which you have to learn how to use each time a reason for using them comes around. -- Horst von Brand [EMAIL PROTECTED] Casilla 9G, Vin~a del Mar, Chile +56 32 672616 ___ kbuild-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: Request for comment -- a better attribution system
"Eric S. Raymond" <[EMAIL PROTECTED]> said: > Alan Cox <[EMAIL PROTECTED]>: > > It scales perfectly. > I must say, in the most respectful way possible, "bullshit!" > Alan, if MAINTAINERS scaled perfectly I wouldn't have had to spend three months > just trying to figure out who was reponsible for each of the [Cc]onfig.in > files. And even with that amount of effort mostly failing. What makes you think your scheme will fare any differently? [...] > I'm an unusually stubborn and persistent person, as you have cause to > know. I really wonder how much good work we've lost because people less > stubborn than me simply gave up on the friction costs of trying to identify > the responsible person(s) for the bits they wanted to change. They post on LKM as last resort. -- Horst von Brand [EMAIL PROTECTED] Casilla 9G, Vin~a del Mar, Chile +56 32 672616 ___ kbuild-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/kbuild-devel
