Re: [kbuild-devel] kbuild mailing list has moved
[added the owner of the old list] Sam Ravnborg wrote: The vger postmasters has created linux-kbuild on my request. The old list at sourceforge had a few issues: - it was subscriber-only - it were relying on moderation For me it is ok. It was subscriber-only because this was a very low traffic mailing list (but with daily spam). BTW, IIRC spam problem began only when we moved to sf.net. Anyway, from the beginning there was problem with moderation. I think because this list is to much low-traffic, to high spam/true message ratio and no more active moderators) Considering the nearly inexistent spam in vger, I think it is a good move. ciao cate - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ kbuild-devel mailing list kbuild-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Re: kbuild: Problem with latest GNU make rc
Sam Ravnborg wrote: sr Suggestion: sr We are now warned about an incompatibility in kbuild and we will sr fix this asap. But that you postpone this particular behaviour sr change until next make release. Maybe you add in this change as sr the first thing after the stable relase so all bleeding edge make sr users see it and can report issues. I am willing to postpone this change. However, I can't say how much of a window this delay will give you: I can say that it's extremely unlikely that it will be another 3 years before GNU make 3.82 comes out. One year would be good. The fixed kernel build will be available in an official kernel in maybe two or three months form now. With current pace we will have maybe 3 more kernel relase until this hits us. And only on bleeding edge machines. I don't think is a big issue. The short-cut compile only the necessary files is used mainly by developers. Anyway the kernel will remain correct. Maybe for old kernel it take more time to build the kernel, but correct. BTW Debian building tools (IIRC) clean the sources before every kernel building process, and in 2.4 (and previous) it was high recommended to clean and recompile all kernel before any changes, so no big issue in these cases. I don't know other normal use, but I think it is not a big issue if people will need a complete build in the rare (IMHO) case that they want to recompile kernel (with small patches or changes in configuration). ciao cate --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ kbuild-devel mailing list kbuild-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Re: kbuild: Problem with latest GNU make rc
Jesper Juhl wrote: On 3/6/06, Giacomo A. Catenazzi [EMAIL PROTECTED] wrote: Sam Ravnborg wrote: sr Suggestion: sr We are now warned about an incompatibility in kbuild and we will sr fix this asap. But that you postpone this particular behaviour sr change until next make release. Maybe you add in this change as sr the first thing after the stable relase so all bleeding edge make sr users see it and can report issues. I am willing to postpone this change. However, I can't say how much of a window this delay will give you: I can say that it's extremely unlikely that it will be another 3 years before GNU make 3.82 comes out. One year would be good. The fixed kernel build will be available in an official kernel in maybe two or three months form now. With current pace we will have maybe 3 more kernel relase until this hits us. And only on bleeding edge machines. I don't think is a big issue. The short-cut compile only the necessary files is used mainly by developers. Anyway the kernel will remain correct. Maybe for old kernel it take more time to build the kernel, but correct. BTW Debian building tools (IIRC) clean the sources before every kernel building process, and in 2.4 (and previous) it was high recommended to clean and recompile all kernel before any changes, so no big issue in these cases. I don't know other normal use, but I think it is not a big issue if people will need a complete build in the rare (IMHO) case that they want to recompile kernel (with small patches or changes in configuration). Rebuilding the kernel tens (or hundreds) of times may be rare for most ordinary users, but it's quite common for kernel developers. Rebuilding the entire kernel every time you make a small change is a big problem and cost a lot of people a lot of time - and the people who will bear the cost are the ones who have to build many kernels. IMHO this is a big problem. I think we misunderstand. Developers will use recent kernel. So a patched kernel that work also with newer make. Only normal user will eventually use old kernel, thus the build infrastructure will not work correctly (aka it will rebuild build the whole kernel everytime) if they use a future make. ciao cate --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ kbuild-devel mailing list kbuild-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] RFC: kernel config: new dependency syntax
Peter Samuelson wrote: * 'or' placed between dependencies functions as a logical OR, and takes very low precedence. This complements the implicit AND performed between every pair of dependencies. x or x - x, for any x n or m == m or n - m n or y == y or n - y m or y == y or m - y I don't like calling it or... It is error prone because it is a non binary system, thus can confuse the lazy developers. Better min. Also I don't like the construct if_dep that parse multiple lines. IMHO better a single line statment: if_dep ..cond.. then ..cml1_statment.. ciao giacomo * A=B evaluates to either Y or N, depending on whether A is logically equivalent to B. It has higher precedence than the ! operator. Thus: CONFIG_FOO=m evaluates to 'y' if CONFIG_FOO is m, 'n' otherwise CONFIG_BAR=n evaluates to 'y' if CONFIG_BAR is n or empty, 'n' otherwise !CONFIG_BAZ=y evaluates to 'n' if CONFIG_BAZ is y, 'y' otherwise This syntax is fully backward-compatible. Examples of use: if_dep CONFIG_X86 or CONFIG_X86_64 or CONFIG_IA64 bool 'ACPI support' CONFIG_ACPI endif if_dep CONFIG_SOUND !CONFIG_SOUND_ALSA source sound/oss/Config.in endif dep_tristate 'Adaptec (new driver)' CONFIG_AIC7XXX_NEW !CONFIG_AIC7XXX_OLD dep_tristate 'Adaptec (old driver)' CONFIG_AIC7XXX_OLD !CONFIG_AIC7XXX_NEW The one thing I wanted to specify but didn't is an 'else' statement. The problem is that I can't think what to call it - can't use 'else' because the shell-based parsers (Configure, Menuconfig) will choke on it. Any ideas? Any other comments? Am I going in totally the wrong direction? Peter --- This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1refcode1=vs3390 ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] KBUILD_SRCTREE_xxx proposal
Hello.
I have some problem with the KBUILD_SRCTREE, and
reading the kbuild-2.5 makefile and the CML2, I
think I'm not alone.
I don't like the actual syntax, so I propose some
improvements, and it is difficult to apply in non
gcc cases.
kbuild-2. should set the internal variable
kbuild_scrtree that is a list of all KBUILD_SRCTREE
(in a format like the PATH), thus easy to use with
other programs.
to do this:
kbuild_srctree=
for evar in ${!KBUILD_SOURCETREE_*} ; do
if [ x$kbuild_srctree = x ] ; then
kbuild_srctree=${!evar}
else
kbuild_srctree=${!evar}:$kbuild_srctree
fi
done
To be more POSIX compatible we should substitute
${!var} to the $(echo $var).
This will simplify the use of multiple source
in applications.
Also the Makefile (instead of hard coded
SCRTREE_000 and CML2 (parsing the 'source' token
should use it.
To extract the right file in shell:
OPATH=$PATH
PATH=$kbuild_srctree
type -p file_without_dir
PATH=$OPATH
or the old method.
OIFS=$OIFS
IFS=:
for src in $kbuild_srctree ; do
if [ -e $kbuild_srctree/FILE_WITH_MAYBE_DIR ] ; then
echo $kbuild_srctree/FILE_WITH_MAYBE_DIR
break
fi
done
IFS=$OIFS
IMHO in python will be a lot simpler.
giacomo
___
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
Eric S. Raymond wrote: Linus Torvalds [EMAIL PROTECTED]: Eric, this is the _wrong_approach_. I want /local/ files, not global ones. First: where should the prompt-string definitions for capability symbols that occur in multiple port trees live? Proposal: the main cml script in linux root dir should be as little as possible. it will include all the arch/*/ cml files (for really specifific options) and you move other item into the subdir drivers/ (the natural place, all file who should not be in driver/ are by definition arch specific). Second: Forward references, and references across the tree, mean that there is a class of symbols that have theoretically natural home directories but which would have to be declared elsewhere in order to be defined at the point of first reference. (A potential solution to this would be to improve the CML2 compiler's handling of forward references.) No. CML2 could be improved to handle che forward references, but not user that will use line config. Third: I could hack my installer to break Configure.help up into a bunch of little component CML files distributed through the tree... but Configure.help doesn't currently contain any markup that says where to direct each entry to. The Makefile should help you. Fourth: There's still the localization issue. If it's your ukase that this is not an important problem, then I'll accept that -- but I haven't heard you say that yet, so I'm not sure you've considered it enough. PROPOSAL: You add a tool to build a big file from the sparse symbols.cml. Translator will use this file as references, adn your CML2 will use translated big files or the default sparse little files. This should not be a problem, because a translator will read documentation (unlike the most user), so you can explain how to do this work. (And the 'diff' could be a friend to the translators). kbuild-2.5 have already support for 'clean' driver (clean: driver that don't touch existing files). I like it. If CML2 could handle natively also these change it would great. The problem is the use of multiple sources dir. I think you and Keith should coordinate this work. And I find clean if also configuration files go into makefiles. giacomo PS: Keith: How you handle the obsolete files? (foo.c in the main source. the patch in source src1 will remove this file). Actually I have create a shell script kpatch: a new implementation of scripts/patch-kernel, that handles normal, testing and testing/incr patches, dont-use patches, multiple sources and new (and clean) destination dir). ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] autoconfigure.sh and cmlconfigure.py design philosophy
Eric S. Raymond wrote: There is a third possibility. autoconfigure.sh is going to pass its results to cmlconfigure.py in a file with the format of a config.out. Right now all those results are symbol bindings (FOO=y, BAR=n). Conceivably autoconfigure.sh could also pass a directive like finished PCI which would tell cmlconfigure.py that all PCI-dependent symbols not yet set should be set to `n'. Either of these alternatives (autoconfigure.sh querying the rulebase or passing a directive to cmlconfigure.py) could work nicely. Which is the right thing is really a question of design philosophy -- that is, what do we *want* the roles of autoconfigure.sh and cmlconfigure.py to be? And how closely coupled should they be? I already thinked two possibilities (there are similar to your alternatives). 1) From CML2 rules I derive all symbols that depends on some rules. The new tables are included in autoconfigure.sh This can be done in Makefile, so the symbols are always updated, and the autoconfigure is still simple shell, so it can be run to the TARGET machine. (easy ? python script). 2) I give CML2 some rules, and set the symbols (not already set) according to these rules. (complex hack in CML2 ?) These rules IMHO can be more complex. I.e. I think that for PCI I should use the if PCI and not PCI_HOTPLUG then set no. Then CML2 should ask user if he want HOTPLUG support, and then eventually the PCI_HOTPLUG card. (I should detect the PCI_HOTPLUG, but yet is a edge feature, so I know little about this, but anyway it is a simple example). For the syntax of autoconfig.out, I think it better to hide such rules in meta-commens (e.g. #:RULES ...) I have no preferences. giacomo ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Re: get_versions.sh
Eric S. Raymond wrote: CONFIG_UTIL_LINUX=y CONFIG_UTIL_LINUX_VERSION=2.11g which: no pppd in (.:/home/esr/bin:/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/sbin/:/usr/sbin:/sbin:/usr/local/sbin:/usr/sbin) CONFIG_E2FS=y CONFIG_E2FS_VERSION=1.23 which: no cardmgr in (.:/home/esr/bin:/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/sbin/:/usr/sbin:/sbin:/usr/local/sbin:/usr/sbin) Looks like a good start. For CML2 purposes you should string-quote the version numbers. Ok I will do it. Also you probably don't want the which output lines in there. This is the old and know (but fast forget) RH which. A lot of script rely on empty output of failing which (and without the special syntax for shell aliases). Only wednesday I will have access to a RH machine, so can you confirm that the error of which are printed on stderr? autoconfigure seems to fail... autoconfigure.sh: 1151able: value too great for base (error token is 1151able)snark:~/src$ hmm, this is a simple problem to solve. I hate the new xemacs mouse copy/paste! giacomo ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Request for comment -- a better attribution system
"Eric S. Raymond" wrote: 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. In this system, most files will contain a "map block". A map block is a metadata section embedded in a comment near the beginning of the file. Here is an example map block for my kxref.py tool: Good! And here's what a map block should look like in general: %Map: T: Description of this unit for map purposes P: Person M: Mail patches to L: Mailing list that is relevant to this area W: Web-page with status/info C: Controlling configuration symbol D: Date this meta-info was last updated S: Status, one of the following: There may be more than one P: field per map block. There should be exactly one M: field. The D: field may have the special value `None' meaining that this map block was translated from old information which has not yet been confirmed with the responsible maintainer. Note that this is the same set of conventions presently used in the MAINTAINERS file, with only the T:, D:, and C: fields being new. The contents of the C: field, if present, should be the name of the CONFIG_ symbol that controls the inclusion of this unit in a kernel. (Map blocks are terminated by a blank line.) We should use the same filed name of CREDITS e.g. D: for Description. (maybe you can invert D: description and T: time of last update) It whould nice also if we include the type of the license (GPL,...). This for a fast parsing (and maybe also to replace the few lines of license) Instead of C: it is more important (IMHO) to include the module name. Maybe we can include both (modules name are always lower case). I think that the inclusion of the config option is not important ( considering that it can be easily parsed from the kaos' new makefiles). giacomo ___ kbuild-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/kbuild-devel
