[kaos]
select_cond(CONFIG_ISDN CONFIG_ISDN_PPP slhc.o)
Both configs must be selected, either as 'y' or 'm'. The first config
defined how the object is compiled. I am worried that this might be
confusing, some users are bound to get the config options in the wrong
order. Any ideas for a
[Alan Cox]
find $TOPDIR -name *.cf -exec cat {} \; Configure.help
[Horst von Brand]
cat `find $TOPDIR -name *.cf` Configure.help #;-)
[Arnaldo Carvalho de Melo]
whatever is faster, do you have trustable benchmark numbers? ;)
Fewer forks vs. increased parallelism ...
[esr]
* The `vitality' flag is gone from the language. Instead, the
autoprober detects the type of your root filesystem and forces
its symbol to Y.
[Russell King]
This seems like a backwards step. What's the reasoning for breaking
the ability to configure the kernel
[esr]
The version I just released does exactly that. Well, not exactly; it
actually looks at fstab -- /proc/mounts gives you '/dev/root' rather
than a physical device name in the root entry.
/etc/fstab is hardly guaranteed to be accurate either. The kernel
mounts the root device based on
[Brendan J Simon]
OK. I saw the instructions. kbuild-2.5-2.4.17-1 says to patch
against the linus-2.4.17 kernel where as kbuild-2.5-2.4.16-ppc-2 says
to patch against the marcelo kernel. I did a search on google and
found Marcelo's directory of kernels. Are these specially patched
[A Guy Called Tyketto]
Just an FYI.. when one runs 'make xconfig', and goes to request help
on a certain option given, a message comes up:
Known issue. Configure.help has been split up, menuconfig and xconfig
don't know this yet. If you want to fix it, feel free. It's probably
not
[[EMAIL PROTECTED]]
I want to know where all i have to make entries in the source code of
linux so that while building the Linux kernel i can include my device
driver in the kernel.
There are files in many of the directories of the kernel called
'Config.in'. Find an appropriate one and add
[kaos]
Can anybody do an up to date set of Makefile.in files for 2.4.18 and
2.5.5?
Working on it ... hope to have something in a few hours, unless someone
beats me to it.
Peter
___
kbuild-devel mailing list
[EMAIL PROTECTED]
[Peter Samuelson]
I'm working on the 2.4.18 version (Keith's latest is -pre1), unless
someone else gets one out first..
Done, see http://wire.cadcamlab.org/misc/kbuild/ .
This was much easier than 2.5 as it didn't have ALSA. (:
I will try to find time to test all this later today.
Peter
[Dominik Brodowski]
So my suggestion is that in a first step the Makefile.in in each
directory could be parsed to the existing form of Makefiles[*], with
the rest of the build system staying the same. This Makefile.in -
Makefile (per directory) parsing could be done as first step of make
[CCs trimmed]
[Sam Ravnborg]
Obviously the kernel build system should work for everyone irrespective
of the SCM system in use. This put at least the following demands:
1) Separate OBJ and SRC tree
2) That kbuild does not touch any files in the SRC tree
Agreed. It looks
[Greg Banks]
I think the problem of Makefile bits in shadow trees is really quite
difficult. Keith's solution of pre-processing Makefiles and
Makefile.appends from all the shadow trees into a combined Makefile
doesn't handle all the cases but is the best attempt I've seen so
far.
Agreed..
[Sam Ravnborg]
This does not stop any attemp to make a simple wrapper that
creates and maintain a BUILD_TREE.
To check timestamps and link accordinly should not take too much
time, at least not at the second run.
[Greg Banks]
Ok, why don't you and Peter Samuelson get together, create
[I wrote]
(cd $s; find * -type d) | xargs mkdir -p;
(cd $s;
exec find * \( -type d -exec mkdir \{} \; \) -o \
\( -type f ! -name \*.prepend ! -name \*.append -print \) ) |
while read f; do
This is redundant - the second mkdir is not needed.
Should be:
(cd $s; exec find *
+48,15 @@
#
# 24 January 1999, Michael Elizabeth Chastain, [EMAIL PROTECTED]
# - Improve the exit message (Jeff Ronne).
+#
+# 8 Aug 2002, Peter Samuelson [EMAIL PROTECTED]
+# for dependencies in dep_* functions:
+# - deprecate '$' (dep_bool 'foo' CONFIG_FOO CONFIG_BAR CONFIG_BAZ)
+# - allow negation
[Peter Samuelson]
!y == n
!m == n
!n == y
[Roman Zippel]
I would define !m as m, e.g. it would allow
dep_tristate CONFIG_OLD !$CONFIG_NEW
dep_tristate CONFIG_NEW !$CONFIG_OLD
You know, that never even occurred to me. Your scheme is not strictly
logical, but it is much more
[Greg Banks]
I like the basic idea here, and I'm pleased that someone has the
courage to tackle some of the brokenness of the kconfig language (if
only because it will provide me with a precedent when I try to
submit some of my patches ;-).
Thanks for the feedback. (:
This applies to
[I wrote]
This stuff is trivial enough, and easy enough to test, that I
think it could go in 2.4, yes.
[Greg Banks]
I think you're underestimating the Gordian knot that is the CML1 corpus.
Yes, very possibly.
To pick an example, in 2.5.29 drivers/ide/Config.in:17 is
dep_tristate
[Roman Zippel]
with the latest modifications this can be written as:
dep_tristate NEW !OLD
dep_tristate OLD !NEW
This still has the back reference and you have to run 'make config'
twice to change NEW from n to y.
I don't see this as a big problem. Most people don't use the bare
[Greg Banks]
Ah. If you're willing to knowingly feed Linus with patches that
break current config behaviour, then OK we have a way to proceed.
Things knowingly break in 2.5 all the time. I for one have no problem
with this. Especially since the breakage is so easy to pinpoint,
thanks to
[Greg Banks]
Ok, here it is.
Thanks again. It will take some time to double-check what I termed
the false positives, but now you've reduced the interesting cases
down to 30 symbols.
(BTW, the format is great - I can use 'M-x compile' and 'M-x
next-error' and Emacs pulls up files and lines
[Sam Ravnborg]
How about extending the language (side effect) to automagically
append (EXPERIMENTAL) or (OBSOLETE) to the menu line, if dependent
on those special tags?
I've thought about that too. Menuconfig already has magic code to
append ' (NEW)' if it hasn't seen a symbol before.
Your
and set all found symbols to n, if unset - only
then do the actual source.
Ugly - I'd rather not have to do it that way. (:
Anyway, some more points:
o a) dep_bool ' Blah' CONFIG_FOO $CONFIG_BAR vs.
b) dep_bool ' Blah' CONFIG_FOO CONFIG_BAR
(the latter proposed by Peter
[I wrote]
sed '/dep_/s/ \$CONFIG_/ CONFIG_/g' is quite effective. In any
case it is not hard to support both syntaxes - once the transition
is complete,
[Greg Banks]
Does complete mean all the ports have also made the change and
been merged back?
Either that, or, Linus gets tired of
[Greg Banks]
define_bool CONFIG_QUUX y
bool 'Set this symbol to ON' CONFIG_FOO
if [ $CONFIG_FOO = y ]; then
bool 'Here QUUX is a query symbol' CONFIG_QUUX
fi
It's (somewhat) well-known that things tend to fly apart when you try
to redefine a symbol. I don't see
[Greg Banks]
[I wrote]
(BTW, the format is great - I can use 'M-x compile' and 'M-x
next-error' and Emacs pulls up files and lines for me.)
This is not a coincidence.
Indeed not - if you hadn't already used that format I would have
munged it. Grew up on gcc, so this is my favorite
Here's another one - this should fix the forward dependency between
CONFIG_SOUND and CONFIG_SOUND_ACI_MIXER, by moving the sound config
into the Multimedia menu - where I think it belongs anyway.
The big loser here is ARM - it no longer suppresses the sound card
question for the appropriate
[I wrote]
Here's another one - this should fix the forward dependency
between CONFIG_SOUND and CONFIG_SOUND_ACI_MIXER, by moving the
sound config into the Multimedia menu - where I think it belongs
anyway.
[Kai Germaschewski]
Hmmh, makes sense to me, but there will probably be people
[Sam Ravnborg]
Where comes the requirement that we shall keep the existing shell
based config parsers?
I don't make that argument - mconfig is the superior solution by far -
but it is certainly the path of least resistance.
As pertains to CONFIG_EXPERIMENTAL and (EXPERIMENTAL), it *is*
drivers/char/Config.in still has a complete copy of agp/Config.in.
It's an exact cut-n-paste - the md5sums even match. (:
--- 2.5.31/drivers/char/Config.in~ 2002-08-08 22:43:28.0 -0500
+++ 2.5.31/drivers/char/Config.in 2002-08-14 17:25:20.0 -0500
@@ -173,21 +173,7 @@
(), dep_bool().
-#
+#
+# 14 Aug 2002, Peter Samuelson [EMAIL PROTECTED]
+# - add lots of new syntax for dependencies in 'dep_*' functions
+# - also use this syntax for a new 'if_dep' / 'endif' primitive
#
@@ -112,6 +115,67 @@
eval info=\$INFO_$1
}
+
+# Reduce a dependency line down
[Greg Banks]
+ dep_tristate ' I2C bit-banging interfaces' CONFIG_I2C_ALGOBIT $CONFIG_I2C
Are you sure want this one there?
I didn't like it either, but it's needed in a couple odd places. What
would you suggest - moving the whole i2c menu up?
Not all the way up to the new
[Brendan J Simon]
Either if_dep, else_dep and end_dep _or ifdep, elsedep, enddep.
I like it. My original if_dep was ifdep, but I thought people would
mistake it for the common verb 'ifdef' and misspell it that way. So I
vote for the _s.
[Greg Banks]
Yes, the _s should be consistent.
Greg, in regards to another question you had - no I don't think there
is value in having a variant if statement that treats 'm' differently.
You can already get the same effect by using 'CONFIG_FOO=y' or
'CONFIG_FOO=m' instead of plain 'CONFIG_FOO'.
You are much better than I at finding
[Giacomo A. Catenazzi]
I don't like calling it or... It is error prone because it is a non
binary system,
thus can confuse the lazy developers.
I had to call it something. I for one think 'or' is quite intuitive
here. If you insist that OR can only be done on binary values, think
of
[Kai Germaschewski]
Honestly, I do not like this. It's probably the best that can be
done in shell, but I think it's ugly and not intuitive.
I accept that it is not pretty. But unless we can switch to mconfig
or gcml2 or some other static parser for everything, we will need
shell-parsable
[Greg Banks]
I was thinking that with your proposed syntax we'd have a large
level of compatibility in both syntax and semantics between if_dep
and dep_bool, much more so than with if and dep_bool
As you said the other day, This is not a coincidence. (:
But technically, if_dep corresponds
[John Alvord]
I've been puzzling about this problem and the CML2 trainwreck.
Maybe we can used advanced tools to remove the many bugs and
inconsistancies and then switch to a better config tool.
That's exactly what we're trying to do. Greg has the advanced
consistency checking, and I've
[Kai Germaschewski]
Seeing it from that point of view, it may actually turn into
something which can agree with much more easily.
Great! I've been hoping for your support - not only because I respect
your judgment, but also because Linus takes patches from you. (:
Maybe it actually
[Roman Zippel]
I really hate to spoil the fun
(:
but could someone explain to me, why this is necessary? What
problems does that fix?
It's not necessary, technically - it doesn't directly fix any bugs.
It falls under cleanup, and as such, it is supposed to make bugs
harder to write and
[I wrote]
I've come up with syntax I think I'm happy with.
Thank you one and all for all the discussion and suggestions for
improvement on my proposals. I've incorporated a lot of feedback.
I know I promised to try and come up with a working prototype
including some Config.in files, but some
[Kai Henningsen]
Incidentally, wouldn't it make sense to use dep_if instead of if_dep?
Yes, probably. I'll go ahead and change it in my tree, unless anyone
objects violently.
Peter
---
This sf.net email is sponsored by: OSDN - Tired of
[Greg Banks]
Ok, we need to be a little bit careful about semantics here, or
there is going to be issues converting the existing corpus.
Agreed.
Currently the if syntax and dependencies are not the same thing;
the if condition is purely a visibility limit, and deps are both
value and
[I wrote]
I guess I wasn't quite clear: my current implementation is both
visibility + value, not visibility only (like current if [ ]) or
value only (like an earlier discussion of dep_if).
[Greg Banks]
Aha. I think you're going to be arguing uphill to get it in.
Could be. Perhaps
[Sam Ravnborg]
+ifdef list-multi
+$(warning kbuild: list-multi ($(list-multi)) is obsolete in 2.5. Please fix!)
+endif
Since kbuild no longer support list-multi this should be $(error )
Except that it is harmless. list-multi is a hint which the kbuild
system no longer needs. Code
[Brendan J Simon]
What is the status of kbuild with respect to getting into the kernel
proper ?
Is it going to get into the linus kernel source tree ??
At this point it doesn't seem likely. Of the rich feature set Keith
produced, Kai Germaschewski has managed to replicate the most
[Brendan J Simon]
Is there a site that documents the changes the Kai has made or is
making ?
Well, there's http://www.??.kernel.org/pub/linux/kernel/v2.5/ChangLog-*,
search for kai@. He seems to have started in 2.5.7.
Off the top of my head, the main kbuild2.5 features 2.5.40 *doesn't*
have
[Brendan J Simon]
Thanks for that information. Looks like Kai's work will/may
eventually do what I want but when will it be mainstream, that is the
question.
If by mainstream you mean in 2.4, probably never. There is just no
motivation to backport it, and I doubt Marcelo would accept the
[Roman Zippel]
The problem is that the config syntax will continue to evolve and
currently I prefer to keep the library close to the matching config
files.
I think I can keep the basic structure constant, but new options will be
added, so IMO it's more likely that a front end works with a
With !KBUILD_VERBOSE output, you can't tell whether a CC or LD line is
for a module or for the kernel proper. Sure, most people probably
don't care, but *I* do. Hence this patch. Output:
CC vmlinux-object.o
CC [M] standalone-module.o
CC (M) partial-module.o
LD built-in.o
[I wrote]
+quiet_modtag = $(if $(findstring $@,$(obj-m)),[M],$(if $(findstring
$@,$(real-objs-m)),(M), ))
Actually s/findstring/filter/g is a bit cleaner.
Peter
---
This SF.net email is sponsored by: ApacheCon, November 18-21 in
Las
[Sam Ravnborg]
Nice.
Thanks.
Does not support CPP or CC -S ... do those even work?
Could you please elaborate - what do you impose by CPP and CC -s?
Maybe it just too late in my timezone...
I'm talking about the built-in rules for .c-.i (preprocessing), .S-.s
(preprocessing), and .c-.s
[Kai Germaschewski]
This looks generally looks okay to me, I don't like the subtle
difference between stand-alone and partial module, though, probably
nobody can remember that, anyway ;) And there is really no difference
in the command line, so why print something different.
The idea was
[Kai Germaschewski]
Well, it's not that my life depends on it ;)
Heh.
But I see the non-verbose mode as an abbreviated view of what
happens, and normally you cannot see the difference between module or
part of module, so it appears inconsistent to have that distinction
in the short view?
[Kai Germaschewski]
I completely agree, though it weakens my argument about consistency ;)
Heh.
Now we only need to convince Peter.
I just sent you a patch with all [M], so I guess you can consider me
sufficiently convinced. I'm not, really, but it's hardly an important
issue, so I figured
Note: this question really belongs on [EMAIL PROTECTED].
[Pannaga Bhushan]
I am looking for a setup where I need to have a certain amount
of data always available to the kernel. The size of data I am looking
at is abt 40MB(preferably, but I will settle for 20MB too) . So the
normal
[Petr Baudis]
Can't say anything about the C++ stuff, but the second user of shared
libraries is going to be lxdialog - hopefully this evening already,
in my patches (it already works, I'm only cleaning out few details
now; lxdialog + mconf is also user of both these extensions).
What is so
[Peter Samuelson]
Basically, what I'm saying is, I see no need for the existing .so in
the kernel build, much less another one. Static libraries are ever so
much easier to manage.
[Roman Zippel]
If you want to limit people to the config tools in the kernel, there
is indeed no need
[Peter Samuelson]
Huh? I don't get it. How is a shared library any better than a static
library in this regard? I'm pondering the traditional advantages of
shared libraries, and I cannot think of a single one that matters here.
[Roman Zippel]
Shared libraries can be loaded
[Roman Zippel]
New features will be added and only the parser that comes with the kernel
will understand them. It's less likley that the library API will change.
Even if this is true - I'll grant you that it may be - let the vendor
package /usr/bin/qconf as a shell script that links
[Roman Zippel]
If your build environment doesn't support shared libraries, you can
easily generate a static library instead and link against it
yourself, like you described, but it's no reason to deny the
convenience to working environments.
Yeah, but until I do, I can't even run 'make
[Petr Baudis]
I'm a bit lost here - the kernel uses tons of gcc extensions - how is
another compiler supposed to understand them? And if it is
specifically extended to understand them, isn't it likely that it'll
understand the -shared switch in gcc-like way as well?
There is a difference
[Tom Rini]
First, does anyone see any problems with the patch itself?
Well,
- str_config += sizeof(CONFIG_) - 1;
+ str_config += strlen(str_split_token);
it does seem a bit inefficient to call strlen() for every single line
of every single source file. Perhaps today's compilers
[Christoph Hellwig]
Well, if you want separate copies of it you have to make sure the
symbols won't clash, e.g. calling all functions in it
MYPREFIX_foo
and then do #define MYPREFIX KBUILD_MODNAME
...or just move everything into a header file as static functions.
Inline, even, if the
[Hussain, Farhad]
request_module[nls_iso8859-1]: Root fs not mounted
Unable to load NLS charset iso8859-1
Kernel panic: VFS: Unable to mount root fs on 03:02
Debice 03:02 is /dev/hda2. It probably means either
a) your root device is somewhere other than /dev/hda2
b) you don't have the
65 matches
Mail list logo
