Re: [kbuild-devel] linux 2.6.1 - ide.ko has unresolved symbols if compiled as module
Hi Sam, Any reason to keep kbuild-devel around still? I do not need it, but I follow what is going n here - of course. In MAINTAINERS for 2.6 I left it out. Well, the address is still embedded in millions of CD-ROM's with 2.4.X, so I would like to keep it around to receive that kind of mail. Maybe you should request Marcelo to remove your mail address from Configure? That may help long-term. You're right, I'll go do that. What is Marcelo's address? Michael C --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] linux 2.6.1 - ide.ko has unresolved symbols if compiled as module
Sam Ravnborg writes: Today Kai Germaschewski and I are kbuild maintainers, which is also listed in 2.6.2-rc1 MAINTAINERS. Right. I still spam-filter the kbuild-devel mailing list, but that's the extent of my activity. I'm working on gdb now. BTW, I still get mail frequently from mandrake users (and now gentoo users too) about menuconfig problems with their distros. Is there a good FAQ URL I can point people to for that? Michael C --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: Building external kernel modules for 2.6
This list is pretty moribund these days -- try the main linux-kernel mailing list if you don't hear anything here. (And I'm inactive, too). Sorry, Michael C --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: kbuild-devel is dead? [Was: Suggestion for addition to the root Makefile]
Agree. One reason for this is that a couple of times when new stuff has been ready for inclusion, Linus complained that it was developed in a 'closed forum' - and he wants public review on lkml for non-trivial stuff. If Linus said that kbuild-devel is (was) a 'closed forum', then Linus was wrong. kbuild-devel was advertised as the contact list for configuration and makefile subsystems in the MAINTAINERS file, along with hundreds of other mailing lists in MAINTAINERS. The list was open to everyone and maintained public archives. Michael C --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] split-include causing extra recompiles
Keith Owens writes: IMHO, split-include needs to recognise the first time that a variable is seen (no previous split config file) and the variable is 'n'. For this case, split-include should not create the file, i.e. treat it as if the variable was still suppressed. That assumes that all C code behaves the same on CONFIG_DEP= and CONFIG_DEP=n. Formally that is not true, because #ifdef CONFIG_DEP will behave differently. A quick grep of the kernel source: grep -r '#.*if.*def.*CONFIG_' ... finds 10,000 such lines! Although most of them are booleans that will never have a value of . Michael C ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] split-include causing extra recompiles
Keith Owens writes: There is no difference in autoconf.h between a suppressed variable (CONFIG_DEP=, no reference in autoconf) and a variable that is visible but set to n (CONFIG_DEP=n, explicitly undefined). In both cases the variable is undefined. C code cannot distinguish between a suppressed variable and one that is set to n. If there really were no difference, then split-include would not see a difference in include/linux/autoconf.h. Check check check ... the difference is that value n emits a line: #undef CONFIG_DEP Whereas value causes no line at all. Since there is no weird -DCONFIG_DEP going on at the command line, you are right, these cases are equivalent at the C level. Perhaps the way to fix this is to change config/menuconfig/xconfig so that they do not emit anything to autoconf.h for the n case. They still have to do proper four-state variables for .config because they read back in later. There is a difference between the two cases for Makefiles, because make reads .config directly, not autoconf.h. If a makefile incorrectly does ifdef CONFIG_FOO then it gets different results on suppressed and visible variables. I'm a bit wary about hacking split-include but it's probably safe to do what you suggest. Sigh, I feel old and rusty. I used to be on top of this stuff. :-/ Michael C ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Question about export-objs in Rules.make
Wes Smith asks: It seems wrong to me that the .o is left in a different position based on whether it has exported symbols or not. Was this just an oversight, and no one has ever happened to have a subdirectory in their module directory, or is there some reason that Rules.make is written the way that it is? I believe it's an oversight. Michael C ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Re: Disgusted with kbuild developers
Jeff Garzik replies to me: mec I believe that CML1 is rococo and I welcome a replacement. I think that mec leapfrog development is a good strategy here, just as it was for ALSA. jg I think this is a key mistake. See Al's message Of Bundling, Dao, jg I am reading lkml from an archive and I saw only the Friday night messages. I have caught up now. I agree with Al's strategy in Of Bundling, Dao, and Cowardice. Let me talk about the list-based makefiles. Long before I submitted the first list-based makefile to the kernel tree (drivers/sound/makefile), I had a whole rewrite of every makefile. These were the Dancing Makefiles and several ideas came out of them: CONFIG_SMP and list-based makefiles in particular. I never thought I'd be able to get the Dancing Makefiles adopted. I spent a whole year just getting CONFIG_SMP merged! So I came to view it as a useful laboratory project to show what kinds of things were viable or not. Then 2.1.XX developed a real problem with drivers/sound/Makefile. The if-statement based approach was not working. The if-statements changed on every patch level and new bugs came in for every patch level. I said to myself aha, list-based makefiles will solve this problem. I wrote a new drivers/sound/Makefile. Here is the important point: I did not touch Rules.make *at all*. I put some translation lines into drivers/sound/Makefile so that it would just work. Between 2.2 and 2.4, several people -- including Jeff Garzik -- converted a lot more makefiles incremenetally to the new style. This process got about 80% done incrementally. Eventually one of the old-style Makefiles developed a similar problem with new tweaks in every patch level leading to a new batch of bug reports. Linus said something like to hell with this and summarily removed support for the old-style. So ... I leapfrogged in my own work area, but I put out incremental patches that solved problems that other people wanted solved. It was also a very painful process for me. My patches got black-holed numerous times. jg It's impossible to prove that Eric's CML2 rulebase reflects a current jg CML1 rulebase, primarily for this reason. That's an important property and I haven't given enough weight to it. :-( It would be nice if: The new tool reads both CML1 and CML2. Deploy the new tool. People could convert directories to CML2 one at a time. jg Those are meta-properties. Indeed, all my criteria are meta-properties. jg CML2's syntax is not reflective of the direction of being able to plop jg down driver.c and driver.conf and having the config/make system jg magically notice it. This driver.conf idea did not exist when CML2 was invented. So it looks like there is a market opportunity here: a tool that reads CML1 files and also reads some kind of new driver.conf files, which can be written in a fresh new language. jg Would you support the replacement of in-kernel jg configure/Menuconfig/xconfig with in-kernel mconfig? I believe that mconfig is best distributed as a semi-independent package, distributed in the way that modutils is distributed today. I think that's better than in-kernel. Between the choice of in-kernel configure/menuconfig/xconfig and in-kernel mconfig, I would go for in-kernel mconfig. jg If we want to migrate to a point where all kernel configuration is jg maintained solely outside the kernel, I actually support that. But as a jg SEPARATE migration step. I do not want to drop all config tools from jg the kernel and tell people use mconfig in the same breath. My vision of the migration path was that mconfig would be distributed separately and co-exist with configure/menuconfig/xconfig. When the market share of mconfig becomes high enough( (say, 80% to 90%), then drop support for configure/menuconfig/xconfig. Michael Elizabeth Chastain mailto:[EMAIL PROTECTED] love without fear ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: Disgusted with kbuild developers
Nicolas Pitre [EMAIL PROTECTED]: Show us that you're able to write a 1 for 1 functional correspondance between CML1 and CML2 and propose that for inclusion into 2.5 Eric S. Raymond [EMAIL PROTECTED]: This requirement is absurd. When someone designs a new VM, we don't demand that it crash or lock up the system in exactly the same way that the old one did before it can go into the kernel. I disagree with this statement in three different ways. [1] lkml readers are kbuild users, not kbuild developers kbuild is special. The relationship between most lkml readers and most linux kernel code (such as the VM) is the relationship of developers to a corpus of code. The relationship of most lkml readers to kbuild is the relationship of *users* to a corpus of code. I think of everybody that has not submitted patches or written code to kbuild tools as a kbuild user. Oddly enough, people behave differently in their roles as users than their roles as developers. Many people who have actually worked on menuconfig would love to shitcan that monstrosity, but people who run menuconfig don't mind the ugliness of its implementation. The first thing users want to know about a software upgrade is: is it going to break what I am doing right now. In a mature system, it really is better to leave 10 old bugs unfixed rather than introduce one new bug. I believe that is why people ask for functional equivalence, even for bugs. Users do not trust developers to decide which behaviours are bugs! In order to do my work, it has to match some internal concepts I have about correctness, elegance, robustness, all that stuff. But in order for other people to want to use my work, it has to match their concepts of what is useful to them. [2] CML1 is working in the field Your view is that CML1 is as bad as a VM that crashes or locks up. This view is rejected by a significant number of CML1 users, including a lot of influential ones. People are building kernels with CML1 every day. Even if you believe that CML1 as a language has hopeless problems, you should acknowledge that many users do not believe this. So when you show up and say here, CML2 language will solve all your CML1 language problems, you are offering a lot of people something negative or neutral to them. A month ago I was disenheartened about this. It looked like CML1 language was going to be good enough for the entire lifespan of the Linux kernel. Now it turns out that there is a new customer requirement: people want driver.conf files. A new language has the opportunity to define driver.conf files and that would be a significant advantage over CML1. [3] kernel development is highly multi-threaded with interesting locks The kernel development process involves hundreds of people across several trees. It's fundamentally different from one person writing code on one branch of one tree -- the same way that a massive multi-threaded program running on a 256-processor server is programmed differently than a single-threaded program on a uniprocessor. I believe there are development locks. I could probably write a whole essay on the nature of these locks, the atomic operations in the development process, the way that people use multi-phase protocols to get something merged without grabbing giant locks, and so on. Kbuild work has the unfortunate property that it sometimes needs big locks. I think that CML2 involves a giant lock: you want to lock every Config.in file at once, modify it from top to bottom, and commit them all at once. Okay. That's a huge lock, especially considering that at any given moment, lots of people have unmerged work-in-progress, as well as whole parallel trees. Linus can acquire a lock that big, because sometimes he just grabs the Big Kernel Development Lock, changes some interface, and relies on us mortals to patch up the loose edges. This works pretty well because it leverages his vision by letting other people share the grunt work. But I think that Linus prefers to avoid grabbing the BKDL, and it's no use pushing him. I think it would be good for you to think about the nature of this locking process (starting with: is mec onto something here or is he delusional?) Then think about how to get to the end vision of CML2 with a less severe locking strategy. Michael Elizabeth Chastain mailto:[EMAIL PROTECTED] love without fear ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] [PATCH] menuconfig: fix error exit if awk fails
This one-liner fixes an error case in Menuconfig when awk fails.
Written by Andrew Church ([EMAIL PROTECTED]).
Reviewed and tested by Michael Elizabeth Chastain ([EMAIL PROTECTED]).
Submission history:
2002-02-05 submission #1
2002-02-11 merged into patch-2.5.4-dj1.diff
2002-02-13 submission #2
Linus ... would you like me to send you patches directly, or would you
like me to become a stratum 2 maintainer, working through someone else?
Michael Elizabeth Chastain
mailto:[EMAIL PROTECTED]
love without fear
===
diff -u -r -N linux-2.5.4/scripts/Menuconfig linux/scripts/Menuconfig
--- linux-2.5.4/scripts/Menuconfig Tue Jan 29 22:31:46 2002
+++ linux/scripts/MenuconfigWed Feb 13 07:27:59 2002
@@ -689,7 +689,7 @@
# Call awk, and watch for error codes, etc.
#
function callawk () {
-awk $1 || echo Awk died with error code $?. Giving up. || exit 1
+awk $1 || { echo Awk died with error code $?. Giving up.; exit 1; }
}
#
___
kbuild-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] [PATCH] fix xconfig for new help system
Hello Linus,
Here is a patch to enhance xconfig to read the new Config.help files.
Olaf Dietsche wrote this, and Steven Cole passed it on to me.
Testing: Steven Cole tested it, and I tested it.
Please apply this. Also, if you don't want to receive config machinery
patches from me, please let me know who you would like me to send
them too.
Michael Elizabeth Chastain
mailto:[EMAIL PROTECTED]
love without fear
===
diff -u -r -N linux-2.5.3/scripts/header.tk linux/scripts/header.tk
--- linux-2.5.3/scripts/header.tk Mon Jul 2 13:56:40 2001
+++ linux/scripts/header.tk Thu Jan 31 21:19:45 2002
@@ -449,29 +449,24 @@
catch {destroy $w}
toplevel $w -class Dialog
- set filefound 0
set found 0
- set lineno 0
- if { [file readable Documentation/Configure.help] == 1} then {
- set filefound 1
- # First escape sed regexp special characters in var:
- set var [exec echo $var | sed s/\[\]\[\/.^$*\]//g]
- # Now pick out right help text:
- set message [exec sed -n
- /^$var\[\]*\$/,\${
- /^$var\[\]*\$/c\\
+ # First escape sed regexp special characters in var:
+ set var [exec echo $var | sed s/\[\]\[\/.^$*\]//g]
+ # Now pick out right help text:
+ set message [exec find . -name Config.help | xargs sed -n
+ /^$var\[\]*\$/,\${
+ /^$var\[\]*\$/c\\
${var}:\\
- /^#/b
- /^\[^ \]/q
- s/^ //
- /file:\\(\[^\]*\\)/s//\\1/g
- p
- }
-Documentation/Configure.help]
- set found [expr [string length $message] 0]
- }
+ /^#/b
+ /^\[^ \]/q
+ s/^ //
+ /file:\\(\[^\]*\\)/s//\\1/g
+ p
+ }
+/dev/null ]
+ set found [expr [string length $message] 0]
frame $w.f1
pack $w.f1 -fill both -expand on
@@ -494,13 +489,8 @@
pack $w.f1.canvas -side right -fill y -expand on
if { $found == 0 } then {
- if { $filefound == 0 } then {
- message $w.f1.f.m -width 750 -aspect 300 -relief flat -text \
- No help available - unable to open file
Documentation/Configure.help. This file should have come with your kernel.
- } else {
message $w.f1.f.m -width 400 -aspect 300 -relief flat -text \
No help available for $var
- }
label $w.f1.bm -bitmap error
wm title $w RTFM
} else {
___
kbuild-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] CML1 maintainer is back
What the heck, I've decided that it's easier for me to function as the CML1 maintainer than to keep explaining that I have lots of opinion and experience although I haven't actually done any work for two years. I just forwarded a nice xconfig patch to Linus. If he wants me to work through someone else, I'll work through someone else. If he wants to blackhole it, I'll see how business is at the dave jones tree. But I'm hoping that he'll accept it and we can all get back to world domination together. As far as CML2 goes, I'm still for it. Someone's gotta maintain CML1 though. It might as well be someone who is in favor of CML2. Michael C ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] make xconfig whinges about Configure.help
Vanilla 2.5.3 and the patch for it, removes the file. Is this being worked on? make oldconfig will work for now, but just a heads up. I don't know of anybody working on it, but if I see good patches on kbuild-devel, I'll test them and send them Linus-wards. If he doesn't respond maybe he'll be good enough to tell me whom he accepts menuconfig and xconfig patches from these days, and I'll work from there. Michael C ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Re: CML2-2.1.3 is available
horst Whatever happened to Do exactly as CML1 does; leave fixes and extensions horst for later? If you put the kitchen sink into it, it _won't_ go into the horst standard kernel. My opinions: It's important that people who type make config or make oldconfig or make menuconfig or make xconfig will continue to have the same experience as they did before. Bug fixes that 90% or 95% of the users agree make things better are okay. Completely new features are okay. make autoconfigure is not going to change anyone's experience from CML1. The multiple questions about what if I want to configure for a different box indicate to me that Eric's product marketing needs a little work. The product itself is fine, but users are getting the idea that autoconfiguration is part of make config. I would recommend that Eric talk about make autoconfigure rather than the autoprober or autoconfigurator. That makes it more obvious (to me at least) that make autoconfigure is a new feature and does not mess with the established semantics of make config/oldconfig/menuconfig/xconfig. It's fun being retired. I get to pontificate without doing work. :) Michael Elizabeth Chastain mailto:[EMAIL PROTECTED] love without fear ___ 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
[mailing lists trimmed] Christoph Hellwig writes: Indepenand of wether 2.6 will use CML1 or CML2 I hope it won't ship with the actual config tool. It's so much nicer to have mconfig compiled once in /usr/bin instead of compiling menuconfig all the time in the tree. I agree, it's really a userland tool, and belongs in its own tarball/rpm/deb, like modutils. But it's up to the config tool author to decide this. Michael C ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Dead symbols
I can help with two of these. From the 2.0.39 kernel: Kernel profiling support CONFIG_PROFILE This is for kernel hackers who want to know how much time the kernel spends in the various procedures. The information is stored in /proc/profile (enable the /proc filesystem!) and in order to read it, you need the readprofile package from sunsite.unc.edu. Its manpage gives information regarding the format of profiling data. To become a kernel hacker, you can start with the Kernel Hacker's Guide, available via FTP (user: anonymous) from sunsite.unc.edu:/pub/Linux/docs/LDP. Mere mortals say N. Profile shift count CONFIG_PROFILE_SHIFT This is used to adjust the granularity with which the addresses of executed instructions get recorded in /proc/profile. But since you enabled Kernel profiling support, you must be a kernel hacker and hence you know what this is about :-) The 2.4.16 kernel still has profiling support, but the config options have been replaced with a boot option (see init/main.c, look for profile=). Setting the profile= boot option turns on profiling, and the integer value of the option sets the granularity. So I suggest something like this: Kernel profiling support (dead) CONFIG_PROFILE This option used to enable kernel profiling, but is now dead. Use the boot option profile= instead. Profile shift count (dead) CONFIG_PROFILE_SHIFT This option used to set the granularity of kernel profiling, but is now dead. Use the boot option profile= instead. My opinion is that as long as an option exists in the corpus, it is good to have help text for it, even if the help text says this option is dead or this option is a merge artifact, don't bother setting it. Michael C ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] '$*' Considered Harmful?
Yes, I consider $* harmful and useless. (back to lurking) Michael C ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Build system transition plan for 2.5
Actually I think of myself as more emeritus than honcho. My ideas for a roadmap: . pick one patch to go first rather than put both in the same point release. . i favor doing cml2 first, because kaos makefiles depend on the cml. . kaos makefiles have separate source and target trees. it looks like cml2 does not have support for separate source and target: the output file goes into the current directory, and the source files come from a find . command. . i think cml2 needs to honor keith's environment variables, KBUILD_SRCTREE and KBUILD_OBJTREE, plus the forest stuff. If the variables are not there, default to current directory, so that cml2 works with the old Makefiles during the transition period. What do you think? Michael ___ kbuild-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Build system transition plan for 2.5
Oof, both of you want to go first, and there are no killer arguments for which to prefer. esr Fundamentally CML2 doesn't care where the input and output lives. esr Input and output locations are specifiable on the command line with esr defaults to the current directory. Keith, is this everything you need for split source and target? (Do you need multiple input locations?) esr Why do this inside CML2 rather than by macroexpansion in the makefile esr command? I agree. If you have command line options, then that suffices. Michael ___ 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
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] list co-administrator wanted
The list has two new co-administrators, Greg Banks and Keith Owens. Greg and Keith are roughly antipodal to me, so the sun never sets on the kbuild empire. And here's a salute to Bernd Kaindl, who is now retiring, and won't have to look at any more admin mail of the form [EMAIL PROTECTED] wants to post about MAKE MONEY FAST -- click here to accept, hold, reject, or discard. Bernd did all the work in moving to sourceforge and setting up a spam-free list. Michael ___ kbuild-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] list co-administrator wanted
Bernhard Kaindl, the senior list administrator, is retiring. I'm looking for 1 or 2 co-administrators. The list is a Gnu Mailman list with a web front end for administration, which means that most tasks are point-and-click. Here's the major stuff that I do: . flush spam from the spam filter . approve postings from non-members. there's a lot of cross-posting between this list and linux-kernel, so there are a lot of good on-topic replies. . if someone replies several times and they are not a subscriber, i often add them to the approved non-subscriber list. . maintain the bare-bones page site at http://kbuild.sourceforge.net/ . . watch the ESR .sig debate real closely. i haven't felt a need to step in yet. . i flushed one new subscriber from the list because it was an address-collecting mailbot and the owner declined to communicate with me. None of this takes much time, but some of these things have to be done every day. Multiple resources are good, and I am away from my computer every so often. Things I am looking for: . different time zone from me (i'm in new york city). this is nice, but not essential. . different organization from me (i'm with red hat). this is essential to me. organizational affiliations have never been a problem in the kbuild world and i'd like to keep it that way. Interested? Write me. Michael ___ kbuild-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Why recovering from broken configs is too hard
I need some free time to actually run CML2; I haven't used it since 0.7 or so. So if I'm out in left field, someone just bang me with a clue stick. Alan Cox writes: I'm quite happy for oldconfig to continue to do what it did before. I'm quite happy to accept its mathematically imperfect, because it hasnt gone far wrong yet I'm in Alan's camp here. The invariant I care about is: that the config tool always *outputs* a legal configuration. I'm sure that ESR is committed to that invariant. There are lots of different cases that can cause the *input* to be illegal. The three existing flavors of configuration have slightly different ways of handling these cases; basically, they have all been good enough for field deployment. If some option drops out and the developer needs it, they will fire up menuconfig/xconfig and stick it right back in. If some option gets turned on by accident they often won't even notice. And if there's a big tangle of sensitive options, then they will care enough to check the options that they care about in menuconfig/xconfig. And sometimes there will be a case where an option acquires a new dependency and maybe the tool goes down a bogus path. Such as: the user has X86=y SMP=y RTC=n, and then a new patch makes RTC depend on SMP, and then a config tool decides that to fix the problem by setting SMP=n. Shock! The first hacker to figure it out will post to linux-kernel in about an hour. There will be a small wave of people saying I'm trying the bleeding edge 2.5.XX kernel and my SMP seems strange, met by another small wave of people saying that's because It would be nice for CML2 to point out any changes that it makes. But users can do that themselves by diffing the file before and after. People who share multiple configs between multiple revisions of the kernel usually know how to use diff. More generally, CML2 does not have to be perfect. It just has to be a lot better than CML1 in most places, and no worse than CML1 in any significant area. Michael ___ kbuild-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] [PATCH] 2.4.3-ac13 update L: tags for two MAINTAINER entries
Michael, is this correct for your entry? The state of Configure/Menuconfig/Xconfig is no longer Maintained. Orphan is more accurate. Also you can list http://kbuild.sourceforge.net as our web site. It has links to the mailing list archives. The old torque.net address can definitely be retired, but I want to have a discussion first. Should we have a separate kbuild-user list for kbuild users, or should we have one unified list? The argument for separate lists: . It separates out frequently asked questions. This is the way that gcc and gdb operate their mailing lists, and this strategy works for them. . The separate lists could have separate policies for message acceptance. Right now, kbuild-devel accepts messages from subscribers + a known set of non-subscribers; other posts are held for review by an admin (I discard spam and approve everything that's not spam). . The separate lists woud have separate archives, which is more convenient for people who want to fix their own problems by reading the archives. The argument for unified list: . It forces developers to pay more attention to users. This is the way that linux-kernel works: it's a list for developer discussion, and it's also the public list for bug submissions. I'm in favor of a single unified list. If the developers get so many bug reports that they can't work on the next version, then they should improve the software or improve the documentation that goes with it. In particular, if lots of people experience usablility problems, then the docs usually need more work. But I'm interested in other people's opinions before making a decision. Michael ___ kbuild-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] CML2 1.2.2 Idea for yet another feature.
Steven Cole writes: I know this probably smells like creeping feature-itis, but it might be useful to display the kernelrelease string, as in: I did this in the defunct mconfig, and I really liked having it on the screen. I put it on the second line, just below the top title. In order to get the information, I had to open up and parse Makefile, whichis kinda kludgy. It sounds good to me. Michael ___ kbuild-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/kbuild-devel
