Re: [kbuild-devel] CML2 choice funny
Suppose we have split declarations for derivations or defaults of symbols that are shared across architectures. It would then be locally convenient for configuration maintainers to move these declarations from the top-level rules.cml file piecemeal to rules files in different arch subtrees, or elsewhere. The problem is that it then becomes globally difficult for someone reading the rulebase to know what the derivation or default behavior of a symbol actually is. Different pieces of the behavior could be scattered all through the rulebase. One of the systems I worked with used a top level Makefile which read a `Makeconf' file (both of them together were probably 20 lines) which defined what the build was going to be. The build could be characterized by a tuple like [unix, solaris, sparcv9] or [unix, linux, i386] or [vxworks, productname, ppc]. There was directory that housed all the make rules and the order of sourcing them was from the most general to the most particular (for example, common rules first, then unix rules, then linux rules and so on). This, along with some other ways or organizing the source code lead to a a situation where the build rules were scattered (well, they were all in separate files at the top of the source tree in a separate directory for just the make rules). It worked pretty nicely, most of the platform/arch maintainers do local stuff in their own files and things work ok as long as the global or common ruleset was not broken. One of the keys insights (for me at least) from that was that, in build systems, enumerating the variables and getting their behavior from a lot of scattered files is better than conditionals in one big file. A lot of the default behavior came from the common rules, in the above system. -Pragnesh ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] CML2 choice funny
On Thu, 29 Nov 2001 02:46:38 -0500, Eric S. Raymond [EMAIL PROTECTED] wrote: Keith Owens [EMAIL PROTECTED]: I am having some problems with the kernel format option, every arch needs this option but the choice list and default will vary between architectures. I am slowly coming to the conclusion that I need kernel_format_x86, kernel_format_ia64 etc. then suppress the entire choice for each arch rather than trying to suppress individual options on a common entry. Ugh. That's nasty. Can you imagine a change in the spec language that would make this unnecessary? The problem is the default which needs to vary from one arch to another. i386 defaults to bzImage, ia64 to vmlinuz etc. The default choice for one arch may be completely suppressed on another arch. The only way I can see round that is to make the default a variable rather than a string, which introduces its own problems. The other part of the problem is deciding which kernel format choices to suppress. Writing unless (ia64 or x86 or sparc or sparc64 or ...) suppress VMLINUZ is nasty, it really needs the reverse of suppress. Default to suppress, select if any of several conditions are true. unsuppress VMLINUZ if x86 unsuppress VMLINUZ if ia64 unsuppress VMLINUZ if sparc then the unsuppress commands can be in the arch specific rules.cml, instead of one big rule that has to be updated for each new arch. I'm not sure it is worth the effort to change CML2, I can get the same effect by defining per arch symbols. ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] CML2 choice funny
Keith Owens [EMAIL PROTECTED]: Ugh. That's nasty. Can you imagine a change in the spec language that would make this unnecessary? The problem is the default which needs to vary from one arch to another. i386 defaults to bzImage, ia64 to vmlinuz etc. The default choice for one arch may be completely suppressed on another arch. The only way I can see round that is to make the default a variable rather than a string, which introduces its own problems. Right, I see this part. The other part of the problem is deciding which kernel format choices to suppress. Writing unless (ia64 or x86 or sparc or sparc64 or ...) suppress VMLINUZ is nasty, it really needs the reverse of suppress. Default to suppress, select if any of several conditions are true. unsuppress VMLINUZ if x86 unsuppress VMLINUZ if ia64 unsuppress VMLINUZ if sparc then the unsuppress commands can be in the arch specific rules.cml, instead of one big rule that has to be updated for each new arch. The reason that there is no unsuppress is that the default value of the visibility predicate is y. Unsuppresses wouldn't be meaningfuly unless you wrote unless n suppress VMLINUZ somewhere. I'm not sure it is worth the effort to change CML2, I can get the same effect by defining per arch symbols. John Cowan has proposed allowing the default expression in a choice to be a string-valued derive that must be the name of a choice. This kind of type punning makes me cringe, and anyway it would be hard to check at compile time that the returned string is necessarily valid. I think I may have a better idea. Let the default be a ? : name-valued expression. So your format choice could look something like this: choices kernel_format VMLINUX VMLINUZ IMAGE ZIMAGE BZIMAGE default ((X86 or IA64 or SPARC) ? VMLINUZ : BZIMAGE) This kind of expression would be pretty easy to check at compile time. I'm going to stare at the code for a while and scope out what it would actually take to implement this. -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a Probably fewer than 2% of handguns and well under 1% of all guns will ever be involved in a violent crime. Thus, the problem of criminal gun violence is concentrated within a very small subset of gun owners, indicating that gun control aimed at the general population faces a serious needle-in-the-haystack problem. -- Gary Kleck, Point Blank: Handgun Violence In America ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] CML2 choice funny
On Thu, Nov 29, 2001 at 12:16:45PM -0500, Eric S. Raymond wrote: I think I may have a better idea. Let the default be a ? : name-valued expression. So your format choice could look something like this: choices kernel_format VMLINUX VMLINUZ IMAGE ZIMAGE BZIMAGE default ((X86 or IA64 or SPARC) ? VMLINUZ : BZIMAGE) I don't know What about other defaults? If 'vmlinuz' == 'zImage', this might be OK, otherwise we'd need something like: choices kernel_format VMLINUX VMLINUZ IMAGE ZIMAGE BZIMAGE ZIMAGE.INITRD default ((X86 or IA64 or SPARC) ? VMLINUZ : (PPC) ? ZIMAGE : BZIMAGE) unless PPC suppress ZIMAGE.INITRD If I'm reading that right (and I don't know, wouldn't it be default ((IA64 or SPARC) ? VMLINUZ : BZIMAGE), ia64/sparc do vmlinuz, else bzImage). -- 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] CML2 choice funny
On Thu, Nov 29, 2001 at 12:53:42PM -0500, Eric S. Raymond wrote: Tom Rini [EMAIL PROTECTED]: On Thu, Nov 29, 2001 at 12:16:45PM -0500, Eric S. Raymond wrote: I think I may have a better idea. Let the default be a ? : name-valued expression. So your format choice could look something like this: choices kernel_format VMLINUX VMLINUZ IMAGE ZIMAGE BZIMAGE default ((X86 or IA64 or SPARC) ? VMLINUZ : BZIMAGE) I don't know What about other defaults? If 'vmlinuz' == 'zImage', this might be OK, otherwise we'd need something like: choices kernel_format VMLINUX VMLINUZ IMAGE ZIMAGE BZIMAGE ZIMAGE.INITRD default ((X86 or IA64 or SPARC) ? VMLINUZ : (PPC) ? ZIMAGE : BZIMAGE) unless PPC suppress ZIMAGE.INITRD If I'm reading that right (and I don't know, wouldn't it be default ((IA64 or SPARC) ? VMLINUZ : BZIMAGE), ia64/sparc do vmlinuz, else bzImage). I'm not understanding your objection. Is it to the specific rule above, or the proposed mechanism? I'm just pointing out that we'll end up with somelike really long and ugly since there'll be at least 3 'defaults' and probably more. If you think it's better to have lots of the test ? a : b's nested instead of making these things architecutre-specific, that's fine I suppose. -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a Government is not reason, it is not eloquence, it is force; like fire, a troublesome servant and a fearful master. Never for a moment should it be left to irresponsible action. -- George Washington, in a speech of January 7, 1790 -- 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] CML2 choice funny
On Thu, Nov 29, 2001 at 01:15:03PM -0500, Eric S. Raymond wrote: Tom Rini [EMAIL PROTECTED]: I'm just pointing out that we'll end up with somelike really long and ugly since there'll be at least 3 'defaults' and probably more. If you think it's better to have lots of the test ? a : b's nested instead of making these things architecutre-specific, that's fine I suppose. It's a tradeoff. The alternative to a long, ugly declaration in one place would be a bunch of marginally shorter and less ugly declarations scattered to hellandgone through the ruleset. :-) Well, in arch/$(ARCH)/rules.cml or so. I know that the second alternative would be harder to compile and validate. I don't know. How is it harder to validate choice kernel_format_PPC VMLINUX ZIMAGE ZNETBOOT default ZIMAGE choice kernel_format_ix86 VMLINUX ZIMAGE BZIMAGE BZDISK default BZIMAGE Than: choice kernel_format VMLINUX ZIMAGE BZIMAGE ZNETBOOT defeult ((X86) : BZIMAGE ? ((IA64 or SPARC) ? VMLINUZ : ZIMAGE)) unless X86 suppress BZIMAGE unless PPC suppress ZNETBOOT I judge that it would also be a net loss for humans maintaining the code -- too hard to be sure that you know what all the relevant declarations are. Better the big ugly declaration you know than the many smll declarations you know not... Er, but this is an arch-specific question. The humans maintaining it would be the maintainer for that arch, who really should know what's relevant. There's also less of a chance of someone goofying up and accidently forgetting to add unless MYARCH suppress FOOBOOTIMAGE that they just added. There's a problem like this now with unless/suppress declarations, but I saw no way to avoid it there. I guess I didn't read the other posts thourghly enough, what's the exact problem? -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a What is a magician but a practicing theorist? -- Obi-Wan Kenobi, 'Return of the Jedi' -- 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] CML2 choice funny
Tom Rini [EMAIL PROTECTED]: I don't know. How is it harder to validate choice kernel_format_PPC VMLINUX ZIMAGE ZNETBOOT default ZIMAGE choice kernel_format_ix86 VMLINUX ZIMAGE BZIMAGE BZDISK default BZIMAGE Than: choice kernel_format VMLINUX ZIMAGE BZIMAGE ZNETBOOT defeult ((X86) : BZIMAGE ? ((IA64 or SPARC) ? VMLINUZ : ZIMAGE)) unless X86 suppress BZIMAGE unless PPC suppress ZNETBOOT That's not a bad case. The case I'm worried about is the one where the choice menus get split into different files and can't be eyeballed at the same time easily. There's a problem like this now with unless/suppress declarations, but I saw no way to avoid it there. I guess I didn't read the other posts thourghly enough, what's the exact problem? Information distributed through the ruleset in such a way that it's hard to know all the places a given symbol participates. -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a Never trust a man who praises compassion while pointing a gun at you. ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] CML2 choice funny
On Thu, Nov 29, 2001 at 01:30:27PM -0500, Eric S. Raymond wrote: Tom Rini [EMAIL PROTECTED]: I don't know. How is it harder to validate choice kernel_format_PPC VMLINUX ZIMAGE ZNETBOOT default ZIMAGE choice kernel_format_ix86 VMLINUX ZIMAGE BZIMAGE BZDISK default BZIMAGE Than: choice kernel_format VMLINUX ZIMAGE BZIMAGE ZNETBOOT defeult ((X86) : BZIMAGE ? ((IA64 or SPARC) ? VMLINUZ : ZIMAGE)) unless X86 suppress BZIMAGE unless PPC suppress ZNETBOOT That's not a bad case. The case I'm worried about is the one where the choice menus get split into different files and can't be eyeballed at the same time easily. Me too. I'm sort of lost as to why this would all need to be in one file. If I understand things, there's one rules.cml for compile target and 'install' questions. Why? There will be per-arch questions which have no relevance to other arches. But even if those were each in a different rules.cml, I still don't see the problem. If there's a syntax error, the compiler will throw up and tell us where, right? What's a bad thing that could happen? There's a problem like this now with unless/suppress declarations, but I saw no way to avoid it there. I guess I didn't read the other posts thourghly enough, what's the exact problem? Information distributed through the ruleset in such a way that it's hard to know all the places a given symbol participates. On the compiler side of things or the human side of things? All of the rule files become one big file, sort of anyhow don't they? And if someone is asking about FOO in a horribly wierd (file) place, maybe they have a good reason to.. Or are totally missing something and will end up with some wierd behavior possibly. -- 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] CML2 choice funny
Tom Rini [EMAIL PROTECTED]: Information distributed through the ruleset in such a way that it's hard to know all the places a given symbol participates. On the compiler side of things or the human side of things? It's the human side I'm primarily worried about. All of the rule files become one big file, sort of anyhow don't they? No, they don't. There's a top-level file that sources all then others at compilation time. -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a The politician attempts to remedy the evil by increasing the very thing that caused the evil in the first place: legal plunder. -- Frederick Bastiat ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] CML2 choice funny
Eric S. Raymond wrote: Information distributed through the ruleset in such a way that it's hard to know all the places a given symbol participates. But that's what xref tools are made for. In the kernel, the directory (or even the file) is the unit of ownership. I argue that stuff like this *should* be divided into separate files, so that each maintainer can get the stuff right for his version. You called this a weighty argument, but I don't see a weighty rebuttal, given a few tools. I think it's possible your view is distorted because you are maintaining all the rules yourself currently, and you don't want to have to remember where things are. -- Not to perambulate || John Cowan [EMAIL PROTECTED] the corridors || http://www.reutershealth.com during the hours of repose || http://www.ccil.org/~cowan in the boots of ascension. \\ Sign in Austrian ski-resort hotel ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] CML2 choice funny
Tom Rini [EMAIL PROTECTED]: Then what's wrong with putting these in arch/$(ARCH)/rules.cml, or arch/$(ARCH)/boot/rules.cml ? Nothing. But if they aren't single declarations, what's going to *keep* them there? -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a Question with boldness even the existence of a God; because, if there be one, he must more approve the homage of reason, than that of blindfolded fear Do not be frightened from this inquiry from any fear of its consequences. If it ends in the belief that there is no God, you will find incitements to virtue in the comfort and pleasantness you feel in its exercise... -- Thomas Jefferson, in a 1787 letter to his nephew ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] CML2 choice funny
Keith Owens [EMAIL PROTECTED]: In my never ending quest to try something stupid: choices kernel_format # The format that the kernel is to be compiled in VMLINUX VMLINUZ BZIMAGE ZIMAGE default BZIMAGE unless IA64 suppress VMLINUZ BZIMAGE ZIMAGE Will set BZIMAGE because it is the default, even though it has been suppressed. Yoicks. Maybe I'd better put in a compile-time check for default suppression! I am having some problems with the kernel format option, every arch needs this option but the choice list and default will vary between architectures. I am slowly coming to the conclusion that I need kernel_format_x86, kernel_format_ia64 etc. then suppress the entire choice for each arch rather than trying to suppress individual options on a common entry. Ugh. That's nasty. Can you imagine a change in the spec language that would make this unnecessary? -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a Of all tyrannies, a tyranny exercised for the good of its victims may be the most oppressive. It may be better to live under robber barons than under omnipotent moral busybodies. The robber baron's cruelty may sometimes sleep, his cupidity may at some point be satiated; but those who torment us for our own good will torment us without end, for they do so with the approval of their consciences. -- C. S. Lewis ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
