Michael> Hi Jes,
>> Except that it requires that the people who write the patches
>> actually use these tools. There is no way I am going to waste time
>> running menuconfig/xconfig before shipping something.
Michael> These are supported features and I can't remove them from the
Michael> kernel (much as I would like to simply kill xconfig).
If xconfig is known to be broken and nobody wants to fix it then there
is no reason why it cannot be removed from the kernel tree.
>> I am not arguing against the fact that a required keyword was
>> missing, that _is_ a bug. What I am pointing out is that it always
>> seem to be the menu based config tools that break things.
Michael> Go get 2.3.18ac9 and *run* "make config" on it and tell me if
Michael> it works. I haven't, but I'd be really surprised if it did.
Michael> Bash doesn't like missing "then" keywords either.
Ok so I didn't make it clear in the original posting, however my standpoint
is of course: if there was a bug it should be fixed, but it has still
be very painful to deal with changes due to broken config tools
(ie. xconfig) even recently.
>> If it is going to break the readability of the current Config.in,
>> .config and defconfig files then no thanks.
Michael> Ok, I don't need to talk to you any more, because even though
Michael> lots of your criticism is valid, you haven't spent five
Michael> minutes reading the *existing* documentation in
Michael> Documentation/kbuild/config-language.txt, let alone looking
Michael> at my new code.
Right I never read that document, it wasn't there when I started
hacking the kernel and I didn't notice it going in. I am not going to
run off chasing new code on some web site, I want to hack the kernel
not modify scripts.
Jes
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/