Hi Keith,
The main reason is to convert absolute dependency names to $(xxx)
followed by a relative name, where xxx is one of the KBUILD_OBJTREE or
KBUILD_SRCTREE_nnn variables. This conversion allows users to rename
their source and object trees and to compile on one machine and install
on
Hi Keith,
That is exactly what kbuild 2.5 does. The slowdown occurs when
massaging the -MD dependencies from absolute names to relative path
names. To support separate source and object trees, renaming of trees,
different names in local and NFS mode etc., the massage code needs a
list of
On Sun, 6 Jan 2002 09:55:49 +0100,
Martin Mares [EMAIL PROTECTED] wrote:
Is there any reason for processing all the files for each compile
instead of merging them to a single file once at the start of the make?
The main reason is to convert absolute dependency names to $(xxx)
followed by a
On Mon, 31 Dec 2001 20:03:59 -0800,
Mike Touloumtzis [EMAIL PROTECTED] wrote:
On Fri, Dec 28, 2001 at 12:57:58PM +1100, Keith Owens wrote:
Unlike the broken make dep, kbuild 2.5 extracts accurate dependencies
by using the -MD option of cpp and post processing the cpp list. The
post
[EMAIL PROTECTED] (Peter Samuelson) wrote on 31.12.01 in
[EMAIL PROTECTED]:
[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
Alan Cox [EMAIL PROTECTED] said:
Something like:
find $TOPDIR -name *.cf -exec cat {} \; Configure.help
Make that:
cat `find $TOPDIR -name *.cf` Configure.help #;-)
--
Horst von Brand [EMAIL PROTECTED]
Casilla 9G, Vin~a del Mar, Chile
[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 ...
On Saturday 29 December 2001 05:43 pm, Eric S. Raymond wrote:
Tom Rini [EMAIL PROTECTED]:
unless (ISA or PCI) suppress dependent IDE
Just a minor point, but what about non-PCI/ISA ide?
The CML1 rules seem to imply that this set is empty.
There are, apparently, paralell port IDE
Just a minor point, but what about non-PCI/ISA ide?
The CML1 rules seem to imply that this set is empty.
There are, apparently, paralell port IDE devices.
I've never seen one, but we've got drivers for them. See PARIDE and
paride_devices.
There are IDE drives on just about every
On Fri, Dec 28, 2001 at 03:39:02PM -0500, Eric S. Raymond wrote:
It may be that the reason our experiences have been different is because we
focus on different target languages. But I think my experience is an
existence proof that there *is* demand for localization and that meeting
it can
[EMAIL PROTECTED] said:
unless (ISA or PCI) suppress dependent IDE
Just a minor point, but what about non-PCI/ISA ide?
Eric is merely representing the _existing_ rules. Changing the behaviour
can come later - that shouldn't be done at the same time as introducing CML2.
--
dwmw2
On Sun, Dec 30, 2001 at 05:14:22PM +, David Woodhouse wrote:
[EMAIL PROTECTED] said:
unless (ISA or PCI) suppress dependent IDE
Just a minor point, but what about non-PCI/ISA ide?
Eric is merely representing the _existing_ rules. Changing the behaviour
can come later - that
On Sun, Dec 30, 2001 at 05:14:22PM +, David Woodhouse wrote:
[EMAIL PROTECTED] said:
unless (ISA or PCI) suppress dependent IDE
Just a minor point, but what about non-PCI/ISA ide?
Eric is merely representing the _existing_ rules. Changing the behaviour
can come later - that
On Sun, 30 Dec 2001, Christoph Hellwig wrote:
On Fri, Dec 28, 2001 at 03:39:02PM -0500, Eric S. Raymond wrote:
It may be that the reason our experiences have been different is because we
focus on different target languages. But I think my experience is an
existence proof that there *is*
At Fri, 28 Dec 2001 23:20:01 + (GMT),
Alan Cox wrote:
Frankly, I find it very amusing that advocates of i18n efforts tend to
be either British or USAnians. Folks, get real - your languages are
too close to show where the problems are. I can see how doing that
gives you a warm fuzzy
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
Hi,
Taking nothing away from Tridge, I like Tridge, I'd like to see numbers.
I'm sure that Tridge's stuff is great, but we were very motivated to
go well beyond the normal effort when we wrote this code.
How large is your core db stuff? The thing I like about tdb is that it
is very
On Fri, 28 Dec 2001, Linus Torvalds wrote:
Having per-function comment blocks, in contrast, makes sense to have
inline:
- you read the comment when you read the function
- you might even update the comment when you update the function
- you have a reasonable 1:1 relationship.
On Fri, 28 Dec 2001, Legacy Fishtank wrote:
A per-driver metadata file is IMHO clearly the preferred solution.
Note that it doesn't need to be per-driver: there are good reasons to have
combined files too. For example, things like architecture config could
all be in one file, along with
On Sat, 29 Dec 2001, Keith Owens wrote:
Yes, some of the problems with mkdep can be fixed in the current design
but there is one problem that is inherently unfixable. make dep is a
manual process so it relies on users knowing when they have to rerun
make dep AND THEY DON'T DO IT!
Don't be
On Fri, Dec 28, 2001 at 05:31:51PM -0500, Eric S. Raymond wrote:
When I talk about rules that use architecture symbols to suppress
things like bus types I have in mind things like this:
[snip]
unless (ISA or PCI) suppress dependent IDE
Just a minor point, but what about non-PCI/ISA ide?
On Sat, Dec 29, 2001 at 05:43:54PM -0500, Eric S. Raymond wrote:
Tom Rini [EMAIL PROTECTED]:
unless (ISA or PCI) suppress dependent IDE
Just a minor point, but what about non-PCI/ISA ide?
The CML1 rules seem to imply that this set is empty.
RiscPC:
CONFIG_PCI=n
CONFIG_ISA=n
Russell King [EMAIL PROTECTED]:
On Sat, Dec 29, 2001 at 05:43:54PM -0500, Eric S. Raymond wrote:
Tom Rini [EMAIL PROTECTED]:
unless (ISA or PCI) suppress dependent IDE
Just a minor point, but what about non-PCI/ISA ide?
The CML1 rules seem to imply that this set is empty.
On Fri, Dec 28, 2001 at 01:54:42AM +0100, Dave Jones wrote:
How far down the list was make it not take twice as long
to build the kernel as kbuild 2.4 ? Keith mentioned O(n^2)
effects due to each compile operation needing to reload
the dependancies etc.
Each compile needs to reload deps???
On Fri, 28 Dec 2001 04:26:48 -0500,
Legacy Fishtank [EMAIL PROTECTED] wrote:
On Fri, Dec 28, 2001 at 01:54:42AM +0100, Dave Jones wrote:
How far down the list was make it not take twice as long
to build the kernel as kbuild 2.4 ? Keith mentioned O(n^2)
effects due to each compile operation
Ah, OK, I get it. Hey, would it help to have a dbm interface compat
library which uses mmap instead of building the db in brk() space?
mmap for db file seems to be slower. For basic db hash usage and raw speed
nothing seems to touch tdb (Tridge's db hack). Its also portable code which
is
On Fri, 28 Dec 2001 14:14:37 + (GMT),
Alan Cox [EMAIL PROTECTED] wrote:
Ah, OK, I get it. Hey, would it help to have a dbm interface compat
library which uses mmap instead of building the db in brk() space?
mmap for db file seems to be slower. For basic db hash usage and raw speed
On Fri, Dec 28, 2001 at 02:14:37PM +, Alan Cox wrote:
Ah, OK, I get it. Hey, would it help to have a dbm interface compat
library which uses mmap instead of building the db in brk() space?
mmap for db file seems to be slower.
I'll need to see some numbers to back up that statement,
[ Btw, Jeff, any reason why you changed your name to Legacy Fishtank? It
took a few mails before I noticed that it also said garzik in the
fine print;]
One thing that this big flame-war has brought up is that different people
like different things. There may be a simpler solution to this:
So if somebody really wants to help this, make scripts that generate
config files AND Configure.help files from a distributed set. And once you
do that, you could even imagine creating the old-style config files
Something like:
find $TOPDIR -name *.cf -exec cat {} \; Configure.help
Linus Torvalds [EMAIL PROTECTED]:
My pet peeve is centralized knowledge. I absolutely detested the first
versions of cml2 for having a single config file, and quite frankly I
don't think Eric has even _yet_ separated things out enough - why does the
main rules.cml file have
On Fri, Dec 28, 2001 at 08:42:44PM +1100, Keith Owens wrote:
All I need to do is have one server process that reads the big list
once and the other client processes talk to the server. Much less data
involved means faster conversion from absolute to standardized names.
Actually, if you use
On Fri, 28 Dec 2001, Eric S. Raymond wrote:
The design reason is that having a single file with all the symbol-to-prompt
mappings in it is really helpful when you want to localize the rulebase for
another language. I'm still leaning towards keeping symbols.cml together
just to make it
More numbers. I coded up a little program (included below) which
reads paths from stdin, lstats() them, and builds an MDBM of inode -
pathname entries. I ran that 10 times on the 2.4 kernel, which had 8679
files matching *.[chSs]. I did a little tuning of page size and inital
DB size (reduces
Alexander Viro [EMAIL PROTECTED]:
I think this is an issue that is rising in importance. I have no problem
with assuming that kernel hackers are English-literate, but it's no longer
an assumption we should make about people *building* kernels. I want
to encourage CML2 and
Legacy Fishtank [EMAIL PROTECTED]:
For single-file drivers, I like Becker's (correct credit?) system...
about 10 lines of metadata is embedded in a C comment, and it includes
the Config.in and Configure.help info.
I proposed implementing something like this about a year ago (to
replace the
On Fri, 28 Dec 2001, Alan Cox wrote:
So if somebody really wants to help this, make scripts that generate
config files AND Configure.help files from a distributed set. And once you
do that, you could even imagine creating the old-style config files
Something like:
find $TOPDIR
On Fri, 28 Dec 2001, Eric S. Raymond wrote:
I'm not certain what you're objecting to, and I want to understand it.
There are rules that use architecture symbols to suppress things like
bus types. I presume that's not a problem for you, but tell me if it is.
It _is_ a problem for me,
On Fri, 28 Dec 2001, Legacy Fishtank wrote:
I think one thing to note is that dependencies is that if you are smart
about it, dependencies -really- do not even change when your .config
changes.
Absolutely. I detest gcc -MD, exactly because it doesn't get this part
right. mkdep.c gets this
On Fri, 28 Dec 2001, Eric S. Raymond wrote:
Legacy Fishtank [EMAIL PROTECTED]:
Note I am specifically NOT talking about MAINTAINERS and CREDITS.
-PLEASE- don't obscure my point by mentioning them.
It's the same problem, Jeff. Same solution, too.
It's not.
We already have pre-file
Linus Torvalds [EMAIL PROTECTED]:
On Fri, 28 Dec 2001, Eric S. Raymond wrote:
I'm not certain what you're objecting to, and I want to understand it.
There are rules that use architecture symbols to suppress things like
bus types. I presume that's not a problem for you, but tell me if it
Frankly, I find it very amusing that advocates of i18n efforts tend to
be either British or USAnians. Folks, get real - your languages are
too close to show where the problems are. I can see how doing that
gives you a warm fuzzy feeling, but could you please listen to those
of us who have
On Fri, 28 Dec 2001, Alan Cox wrote:
It would certainly fit nicely with the existing metadata. We already rip out
code comments via kernel-doc, and extending it to rip out
- Help text
- Web site
...
No no no.
The comments can at least be helpful to programmers,
Linus Torvalds [EMAIL PROTECTED]:
Eric, this is the _wrong_approach_. I want /local/ files, not global ones.
I hear you. There are some problems with that, however.
First: where should the prompt-string definitions for capability
symbols that occur in multiple port trees live?
(This is an
Alan Cox [EMAIL PROTECTED]:
I'd be happy to take another swing at this problem once the kbuild-2.5/CML2
transition is done. But I don't think we should let it block us from
having the good results we can get from that change.
It would certainly fit nicely with the existing metadata. We
On Fri, 28 Dec 2001, Linus Torvalds wrote:
On Fri, 28 Dec 2001, Legacy Fishtank wrote:
I think one thing to note is that dependencies is that if you are smart
about it, dependencies -really- do not even change when your .config
changes.
Absolutely. I detest gcc -MD, exactly because
cc: list trimmed.
On Fri, 28 Dec 2001 12:01:04 -0800,
Larry McVoy [EMAIL PROTECTED] wrote:
On Fri, Dec 28, 2001 at 08:42:44PM +1100, Keith Owens wrote:
All I need to do is have one server process that reads the big list
once and the other client processes talk to the server. Much less data
I also want updates from the dependency back end code, to remove the
phase 5 processing. The extract dependency code runs after each
compile step so there can be multiple updates running in parallel. My
gut feeling is that it will be faster to have one database server and
all the back ends
On Fri, 28 Dec 2001 14:17:24 -0800 (PST),
Linus Torvalds [EMAIL PROTECTED] wrote:
On Fri, 28 Dec 2001, Legacy Fishtank wrote:
I think one thing to note is that dependencies is that if you are smart
about it, dependencies -really- do not even change when your .config
changes.
Absolutely. I
On Fri, 28 Dec 2001 16:16:03 -0500,
Legacy Fishtank [EMAIL PROTECTED] wrote:
I think one thing to note is that dependencies is that if you are smart
about it, dependencies -really- do not even change when your .config
changes.
What about a system where Linus runs make deps -once- before he
Unlike bio, kbuild 2.5 works, it just needs to be a bit faster. Put
kbuild 2.5 in the kernel and I will have a faster version within 2
weeks.
Ok. I was assuming from what you had said that we were talking about months
before it got up to a sane speed. If its 2 weeks then I have absolutely no
Larry McVoy wrote:
On Fri, Dec 28, 2001 at 12:41:48PM +1100, Keith Owens wrote:
On Thu, 27 Dec 2001 17:37:39 -0800,
Larry McVoy [EMAIL PROTECTED] wrote:
A couple of questions:
a) will 2.5 be as fast as the current system? Faster?
At the moment kbuild 2.5 ranges from 10% faster on small
dammit, didn't hit reply all grr
On Saturday, December 29, 2001, at 05:02 AM, Linus Torvalds wrote:
snip
My pet peeve is centralized knowledge. I absolutely detested the first
versions of cml2 for having a single config file, and quite frankly I
don't think Eric has even _yet_ separated
that if there is reusable code in BK, we're willing to let people use
it under whatever license they want. It would be nice if that actually
happened after all the yelling and screaming.
mdbm is one I've not seen. The timings I've done are with db2/db3/tdb when
I was playing with a fast UDP
Linus Torvalds wrote:
On Fri, 28 Dec 2001, Alan Cox wrote:
It would certainly fit nicely with the existing metadata. We already rip out
code comments via kernel-doc, and extending it to rip out
- Help text
- Web site
...
No no no.
The comments can at least be helpful
On Fri, Dec 28, 2001 at 10:02:01AM -0800, Linus Torvalds wrote:
[ Btw, Jeff, any reason why you changed your name to Legacy Fishtank? It
took a few mails before I noticed that it also said garzik in the
fine print;]
Away-from-home account and a long story :)
Jeff
On Fri, Dec 28, 2001 at 02:27:37PM -0800, Linus Torvalds wrote:
and it's readable and probably trivially parseable into both the existing
format (ie some find . -name '*.conf' plus sed-scripts) and into cml2 or
whatever.
It's even doable within the .c file (and preferable for small drivers).
I think one thing to note is that dependencies is that if you are smart
about it, dependencies -really- do not even change when your .config
changes.
What about a system where Linus runs make deps -once- before he
releases a tarball. This in turn generates dependency information
(perhaps not in
On Fri, Dec 28, 2001 at 03:45:37PM -0500, Eric S. Raymond wrote:
Legacy Fishtank [EMAIL PROTECTED]:
For single-file drivers, I like Becker's (correct credit?) system...
about 10 lines of metadata is embedded in a C comment, and it includes
the Config.in and Configure.help info.
I
Linus Torvalds wrote:
[ Btw, Jeff, any reason why you changed your name to Legacy Fishtank? It
took a few mails before I noticed that it also said garzik in the
fine print;]
One thing that this big flame-war has brought up is that different people
like different things. There may be a
Larry McVoy writes:
On Fri, Dec 28, 2001 at 08:42:44PM +1100, Keith Owens wrote:
All I need to do is have one server process that reads the big list
once and the other client processes talk to the server. Much less data
involved means faster conversion from absolute to standardized names.
On Fri, Dec 28, 2001 at 10:02:01AM -0800, Linus Torvalds wrote:
Something I also asked for the config system at least a year ago was to
have Configure.help split up. Never happened. It's still one large ugly
file. Driver or architecture maintainers still can't just change _their_
small
On Sat, Dec 29, 2001 at 12:26:49PM +1100, Keith Owens wrote:
On Fri, 28 Dec 2001 16:16:03 -0500,
Legacy Fishtank [EMAIL PROTECTED] wrote:
I think one thing to note is that dependencies is that if you are smart
about it, dependencies -really- do not even change when your .config
changes.
On Sat, Dec 29, 2001 at 12:27:24PM +1100, Keith Owens wrote:
Dependencies _do_ change when your .config changes, the list of files
that are included varies.
1) #ifdef CONFIG_FOO #include ... is usually wrong and a bug. But
that is a tangent and I digress.
2) Such changes can be expressed
Dave Jones [EMAIL PROTECTED]:
Maybe keep them both in the
tree until this issue is worked out ? That way those who want to
play with kbuild can do so, and those who build a few dozen
kernels a day don't have to twiddle thumbs.
That is such an unutterably
On Thu, Dec 27, 2001 at 07:57:38PM -0500, Eric S. Raymond wrote:
Dave Jones [EMAIL PROTECTED]:
Maybe keep them both in the
tree until this issue is worked out ? That way those who want to
play with kbuild can do so, and those who build a few dozen
On Fri, 28 Dec 2001 01:54:42 +0100 (CET),
Dave Jones [EMAIL PROTECTED] wrote:
On Thu, 27 Dec 2001, Eric S. Raymond wrote:
..., and Keith's stuff is stable
enough that he's now adding features like kernel-image type selection
that were obviously way down his to-do list.
How far down the list
On Thu, 27 Dec 2001 17:15:45 -0800,
Larry McVoy [EMAIL PROTECTED] wrote:
[talking about kbuild 2.5 speed]
Then it does seem reasonable to ask that the new one is at least as fast
as the old one.
kbuild 2.4 is fast but inaccurate, kbuild 2.5 is slower but accurate.
Pick one.
I am sure that I
On Fri, Dec 28, 2001 at 02:22:01AM +0100, Dave Jones wrote:
On Thu, 27 Dec 2001, Eric S. Raymond wrote:
That is such an unutterably horrible concept that the very tentacles
of Cthulhu himself must twitch in dread at the thought. The last thing
anyone sane wants to do is have to maintain
On Fri, 28 Dec 2001 02:22:01 +0100 (CET),
Dave Jones [EMAIL PROTECTED] wrote:
On Thu, 27 Dec 2001, Eric S. Raymond wrote:
That is such an unutterably horrible concept that the very tentacles
of Cthulhu himself must twitch in dread at the thought. The last thing
anyone sane wants to do is
On Thu, 27 Dec 2001 17:37:39 -0800,
Larry McVoy [EMAIL PROTECTED] wrote:
A couple of questions:
a) will 2.5 be as fast as the current system? Faster?
At the moment kbuild 2.5 ranges from 10% faster on small builds to 100%
slower on a full kernel build. But that is using slow core code which
On Fri, Dec 28, 2001 at 12:35:50PM +1100, Keith Owens wrote:
On Thu, 27 Dec 2001 17:15:45 -0800,
Larry McVoy [EMAIL PROTECTED] wrote:
[talking about kbuild 2.5 speed]
Then it does seem reasonable to ask that the new one is at least as fast
as the old one.
kbuild 2.4 is fast but
On Fri, Dec 28, 2001 at 12:41:48PM +1100, Keith Owens wrote:
On Thu, 27 Dec 2001 17:37:39 -0800,
Larry McVoy [EMAIL PROTECTED] wrote:
A couple of questions:
a) will 2.5 be as fast as the current system? Faster?
At the moment kbuild 2.5 ranges from 10% faster on small builds to 100%
Tom Rini [EMAIL PROTECTED]:
I think Keith wanted a very small time window tho (~24 hrs, barring big
supprises). But if we're going to be worried about the build time,
kbuild-2.5 and cml2 aren't co-dependant, yes? I know kbuild-2.5 works
w/o cml2, and last I tried (ages ago admitedly) cml2
Unlike the broken make dep, kbuild 2.5 extracts accurate dependencies
by using the -MD option of cpp and post processing the cpp list. The
post processing code is slow because the current design requires every
compile to read a complete list of all the files, giving O(n^2)
effects. Mark 2
75 matches
Mail list logo
