Linus (and Marcelo): I understand that right at the moment you have
higher priorities than merging in the new build system. Keith Owens
and I agree with those priorities, so please consider the following to
be information rather than pressure for action.
Keith's kbuild-2.5 and my CML2 both appear to be shaking down quite
nicely.
In the last eight weeks the level of beta testing we're getting from
lkml regulars has risen dramatically, as has the amount of work being
put in on the codebases by people other than Keith and myself (just
last night I checked in an entire new X-based front end contributed by
a hacker from Korea).
Despite the increased attention, the criticality level of incoming bug
reports has held steady or decreased, to the point that we're
basically both just doing normal maintainance and polishing the chrome
now. I haven't seen a really serious bug in CML2 since I resumed
active work on it in early November, 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.
Just as importantly, the kernel development community now seems to be
actively preparing for the build-system cutover, as opposed to just
passively waiting for it. Some are doing their cutover in *advance*
of the main tree; the kinds of kbuild bug reports I see on the list
indicate that Keith's kbuild is already in production use, and in the
last week I've gotten requests from SGI's XFS group and the ELKS
project for help with switching to CML2.
In sum, we're ready now -- but that's been true since at latest early
November. What's new in the last couple weeks is that the developer
community appears to be coming up to speed on our technology
effectively enough to be ready as well.
We can help plan and execute the cutover any time you're ready.
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
When all government ...in little as in great things... shall be drawn to
Washington as the center of all power; it will render powerless the checks
provided of one government on another, and will become as venal and oppressive
as the government from which we separated." -- Thomas Jefferson, 1821
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 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.
Given how early your both pushing to get these into the tree(s),
and given how many kernels are going to be built between now
and 2.6.0, slowing down development for _every_ kernel developer
doesn't strike me as a bright move. 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.
Don't get me wrong, I'm not knocking CML2 or kbuild2.5,
I'm just interested in some of timescale for getting wrinkles
like this out.
Dave.
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs
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 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 two parallel build systems
at the same time.
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
You know why there's a Second Amendment? In case the government fails to
follow the first one.
-- Rush Limbaugh, in a moment of unaccustomed profundity 17 Aug 1993
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
> > kernels a day don't have to twiddle thumbs.
>
> 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 two parallel build systems
> at the same time.
Then it does seem reasonable to ask that the new one is at least as fast
as the old one.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
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 two parallel build systems
> at the same time.
Funny, I could have sworn I read this was Keith's intention at least
for a few pre's. Maybe I misinterpreted his intentions.
Dave.
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs
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 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.
I had to choose between helping other architectures to convert and
rewriting the core code to speed everything up. I chose to get other
architectures converted, finding some interesting "features" at the
same time.
The core code is stable and I will not change it right now, I want
stable code to go to Linus. Once Linus takes kbuild 2.5 then I can
start on the rewrite, without affecting anybody else.
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 inaccurate, kbuild 2.5 is slower but accurate.
> Pick one.
>
> I am sure that I can speed up kbuild 2.5 with a rewrite of the core
> code but I am staying on stable code to send to Linus.
A couple of questions:
a) will 2.5 be as fast as the current system? Faster?
b) what's the eta on 2.5?
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
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 have to maintain two parallel build systems
>> at the same time.
>
>Funny, I could have sworn I read this was Keith's intention at least
>for a few pre's. Maybe I misinterpreted his intentions.
Only long enough to prove that kbuild 2.5 built kernels that worked.
And to give unconverted architectures a kernel that had both old and
new kbuild in it for their conversion. Once kbuild 2.5 has proved it
works, kbuild 2.4 is coming out.
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 can speed up kbuild 2.5 with a rewrite of the core
code but I am staying on stable code to send to Linus.
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 two parallel build systems
> > at the same time.
>
> Funny, I could have sworn I read this was Keith's intention at least
> for a few pre's. Maybe I misinterpreted his intentions.
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 didn't need
kbuild-2.5. So we could, in theory dump cml1 quickly but leave the old
Makefiles for a bit longer. Or if Keith thinks he can start on the
speed problems soon, just plod along for a few releases. :)
--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
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
I know I can rewrite to make it significantly faster.
>b) what's the eta on 2.5?
kbuild 2.5 is ready now. I am not even going to start on the core
rewrite until Linus takes the existing kbuild 2.5 code. The existing
code works and is stable, doing a complete core rewrite just before
includeing in the kernel strikes me as stupid.
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%
> slower on a full kernel build.
I don't understand why it would be slower. Maybe I'm clueless but I thought
you were moving more towards a single makefile system, kind of like what
BSD had about 15 years ago, you went to /sys/MYMACHINE and typed make and
it did the build completely in that directory. You did different configs
by running a configure tool that made /sys/MYMACHINE /sys/YOURMACHINE, etc.
If this is the general approach, shouldn't this be a lot faster than the
current approach? The current approach stats stuff many times. Linux is
really good at making stats cheap, but nothing is as good as not doing it
twice.
Am I completely misunderstanding what kbuild is all about? My apologies
if so...
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
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 didn't need
> kbuild-2.5.
That's right. CML2 and kbuild-2.5 do not require each other
> So we could, in theory dump cml1 quickly but leave the old
> Makefiles for a bit longer. Or if Keith thinks he can start on the
> speed problems soon, just plod along for a few releases. :)
As Keith has pointed out, old kbuild achieves its speed by being broken.
That's an argument for "plod along", IMHO.
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
(Those) who are trying to read the Second Amendment out of the Constitution by
claiming it's not an individual right (are) courting disaster by encouraging
others to use the same means to eliminate portions of the Constitution they
don't like.
-- Alan Dershowitz, Harvard Law School
On Thu, 27 Dec 2001 17:47:23 -0800,
Larry McVoy <[email protected]> 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 builds to 100%
>> slower on a full kernel build.
>
>I don't understand why it would be slower. Maybe I'm clueless but I thought
>you were moving more towards a single makefile system
It uses a single generated Makefile, that is not the problem. The slow
code is extracting the dependencies.
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 of the core code will use a shared database with
concurrent update so post processing is limited to looking up just the
required files, instead of reading the complete list every time.
> 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 of the core code will use a shared database with
> concurrent update so post processing is limited to looking up just the
> required files, instead of reading the complete list every time.
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?
We've got a small, fast one that you can have under any license you
like, GPL, LGPL, whatever. We use it all over the BK code.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
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???
Ug. IMHO if you are doing to shake up the entire build system, you
should Do It Right(tm) and build a -complete- dependency graph -once-.
Jeff
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 needing to reload
>> the dependancies etc.
>
>Each compile needs to reload deps???
>
>Ug. IMHO if you are doing to shake up the entire build system, you
>should Do It Right(tm) and build a -complete- dependency graph -once-.
We have one complete dependency graph for the explicit dependencies.
What is slow is extracting the implicit dependencies after an object
has been compiled, i.e. the files that it includes. Actually
extracting the implicit dependencies is fast, converting them to
standard names is fast, what is slow is _reading_ the big list that
maps from absolute names to standardized names.
I need the big list in order to remove absolute names in the dependency
trees. kbuild 2.4 forces a complete recompile if you rename a tree,
including if you build on one system then try to install via NFS on a
second system. kbuild 2.5 can cope with trees being renamed and trees
having different names on local and NFS mounted systems. That
flexibility comes at a cost.
"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.
> 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 important since the tool has to be built on the compiling host.
Personally I've always considered make dep good enough. Its trying to solve
the extra .5% that probably can be solved by careful use of make clean when
CML realises a critical rule changed (SMP etc)
Alan
> 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
> kbuild 2.5 is ready now. I am not even going to start on the core
"Its 100% slower so its ready"
I must be missing something here. If its 100% slower its not ready.
Alan
On Fri, 28 Dec 2001 14:14:37 +0000 (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
>nothing seems to touch tdb (Tridge's db hack). Its also portable code which
>is important since the tool has to be built on the compiling host.
lm sent me the bk mdbm code but I will look at tdb as well. Four
acronyms in one sentance, I must be a phb :).
>Personally I've always considered make dep good enough. Its trying to solve
>the extra .5% that probably can be solved by careful use of make clean when
>CML realises a critical rule changed (SMP etc)
http://prdownloads.sourceforge.net/kbuild/kbuild-2.5-history.tar.bz2
Especially makefile-2.5_make_dep.html, 9 reasons why make dep is broken
as designed. Some are fixable in the current system, others are
inherently unfixable. I skipped that page when I did my presentation
at the 2.5 developer's conference.
> including if you build on one system then try to install via NFS on a
> second system. kbuild 2.5 can cope with trees being renamed and trees
> having different names on local and NFS mounted systems. That
> flexibility comes at a cost.
So you've halved performance rather than documented that you have to mount
the tree in the space place on every NFS export ? I'm obviously still
missing something here.
Alan
In article <[email protected]> you write:
>Alan Cox <[email protected]> wrote:
>>Personally I've always considered make dep good enough. Its trying to solve
>>the extra .5% that probably can be solved by careful use of make clean when
>>CML realises a critical rule changed (SMP etc)
>
>http://prdownloads.sourceforge.net/kbuild/kbuild-2.5-history.tar.bz2
>Especially makefile-2.5_make_dep.html, 9 reasons why make dep is broken
>as designed. Some are fixable in the current system, others are
>inherently unfixable. I skipped that page when I did my presentation
>at the 2.5 developer's conference.
* make dep is only run once
Personally, I don't see this as a big problem. Just tell people to
always run "make oldconfig && make dep" after patching the kernel
and if they can't read, too bad. I usually compile a kernel a lot
more often than I add include files. Since I'm quite impatient
I often do "make SUBDIRS=drivers/mtd/maps modules" just so that the
compile will go faster, so having to do dependency checking each time
I want to compile feels like an unfortunate tradeoff to me.
* The generated dependencies are absolute
That dependencies are absolute is also not a thing that has bothered me
too much, it's always possible to run "make dep" after moving a tree,
on the other hand, I don't use NFS a lot anymore, so I can see it being
a problem in other environments.
/Christer
--
"Just how much can I get away with and still go to heaven?"
> * make dep is only run once
>
> Personally, I don't see this as a big problem. Just tell people to
I run make dep whenever I change config. Guess what - one cmp and I can
automate that as part of make. If the .config doesnt match the
.configwhendep then its time to make dep again
> That dependencies are absolute is also not a thing that has bothered me
> too much, it's always possible to run "make dep" after moving a tree,
> on the other hand, I don't use NFS a lot anymore, so I can see it being
> a problem in other environments.
sed works too, as do symlinks
On Fri, Dec 28, 2001 at 02:14:37PM +0000, 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, please. If you
look at the graphs produced by LMbench, they tell you exactly what
you need to know. It's true that for very small files, 8K and under,
using read() to access them is faster than using mmap, due to the extra
work of setting up and tearing down the mapping. To quantify this, a
4KB open/read/close is 500MB/sec, but an open/mmap/access/unmap/close
is 425MB/sec. By the time we hit 16K, mmap wins by 15% and just gets
better from there.
And that all assumes you are doing large reads, which in db code you
are not. So mmap will look better even on the small files if you
are doing little DB style accesses.
> For basic db hash usage and raw speed
> nothing seems to touch tdb (Tridge's db hack).
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.
A multithreaded version of the code that I sent to Keith was doing 455,000
lookups/second on an 8way 200Mhz R4400 SGI box in 1996. Each lookup
was locked. If you assume perfect scaling (it was) and you assume the
locks took 0 time (they didn't), that's 1.75 usecs for each lookup.
On a machine with horrible memory latency and a large dataset.
We designed the MDBM code to be scalable (its 64bit clean), portable
(runs on 20+ platforms today), multiplatform (metadata is stored in
network byte order on disk), and fast (we knew exactly what the
instruction and data cache footprint was for hot cache, and we made
sure that you did at most 2 disk accesses, 1 was typical, to get at
any item in a cold cache).
SGI uses this code for their name server, every process mmaps the
name server cache.
We use this code all over BitKeeper.
> Its also portable code which
> is important since the tool has to be built on the compiling host.
The code works on Windows, MacOS X, and basically all Unix platforms.
Yeah, yeah, I pounding my chest and I'm sorry, but I get beat up all the
time that the BK license doesn't let you reuse code and this code is part
of BK that we broke out and licensed under the GPL. The point being
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.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
[ 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: have the
core dependency files generated from some other file format.
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 architecture-specific info, for example?
That's a big step backwards as far as I'm concerned - we didn't use to
have those stupid global files, and each architecture could do it's own
config rules. Eric never got the point that to me, modularity is _the_
most important thing for maintenance.
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 fragment, they have to touch a global file that they don't "own".
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
(without the automatic checking and losing some information) from the
information.
Linus
> 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 server that had to do a db lookup per packet.
Alan
> 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
or changing the tools to look for
Documentation/Configure/CONFIG_SMALL_BANANA
??
Alan
Hi Linus.
> [ 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;]
I had wondered where he'd gone to - Jeff was one of the few from who I
read every email, and it's been a while since I saw anything from him.
> 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: have the core dependency files generated from some other file
> format.
>
> 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
> architecture-specific info, for example?
>
> That's a big step backwards as far as I'm concerned - we didn't use
> to have those stupid global files, and each architecture could do
> it's own config rules. Eric never got the point that to me,
> modularity is _the_ most important thing for maintenance.
>
> 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 fragment, they have to touch a global file that
> they don't "own".
>
> 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 (without the automatic checking and losing some
> information) from the information.
I offered to go through Configure.help and split it up a while back, and
I was drowned in several dozen emails saying that such was a BAD THING,
with absolutely zilch saying otherwise. I'm more than willing to have a
go at splitting it up into separate files by directory, but before I do,
I would need to know how you wished to deal with symbols that are
referenced all over the source tree rather than just in a single
directory.
Another thing I'd like to do is to introduce a "boilerplate" mechanism
whereby help text that's repeated in multiple options gets stored just
once and dragged in when it's needed. I've made a start on doing that
with the current Configure.help file and the `make config` and `make
menuconfig` commands, and have patches available against the 2.0.39,
2.2.20 and 2.4.17 trees to provide the base implementation for `make
config` but gather that such is pointless as those commands will soon be
extracted from the Linux kernel.
Best wishes from Riley.
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 architecture-specific info, for example?
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.
My best guess is that you're objecting to the archihacks and kernelhacking
menus, or the architecture-dependent derivations down around line 330.
In general what's going on here is actually the beginnings of an attempt to
replace architecture-dependent questions with architecture-*independent*
questions. It looks kind of ugly right now because it's too early in
the game to mess with the config-symbol namespace -- but, for example, I
want to merge the MATH_EMULATION and MATHEMU symbols eventually. And
there ought to be a generic set of toggles for kernel-debugging that
present to the user as cross-platform capabilities rather than platform-
specific switches.
In those two menus I've gathered together architecture-specific
symbols that I think ought to merge into cross-platform capabilities.
But I know there is other cruft in there for historical reasons. Since
you've brought up the point, I'll do a cleanup pass on these and see
how much I can exile to the arch/*/rules.cml files.
There isn't really any help for the ceoss-platform derivations. There
are exactly four of these. I've worked hard at holding them to a
minimum:
derive HAVE_DEC_LOCK from (SMP and (ALPHA or X86_CMPXCHG)) or SPARC or PPC
derive HIGHMEM from HIGHMEM4G or HIGHMEM64G or SPARC
derive MAC_HID from (ALL_PPC and INPUT!=n) or (MAC and INPUT_ADBHID)
derive PC_KEYB from ARM_PC_KEYB or MIPS_PC_KEYB
If you notice that each right-hand part includes port symbols from at
least two different architectures, I think it will be clearer why these
are necessary.
CML1's way of doing this had the problem that it was hard to know by
inspection of the rulebase under what circumstances a given symbol was
actually turned on. This is why CML2 has a rule that each symbol is
derived (or occurs in a menu) exactly once. With some work I could
relax this restriction, but I don't want to -- it's a major factor in
keeping the rulebase's complexity down in the range that a human brain
can mentally model.
> That's a big step backwards as far as I'm concerned - we didn't use to
> have those stupid global files, and each architecture could do it's own
> config rules. Eric never got the point that to me, modularity is _the_
> most important thing for maintenance.
Oh, no, I got that all right. What I have been trying to do is trade
off correctly between modularity (which helps maintenance) and the
advantages to the configurator *users* of having a global capability
namespace, single-apex menu structure, and the symbols-to-prompts
mapping in one file. These choices weren't made at random.
You don't readily see their advantages because you have a
nose-to-the-code, maintainer perspective (quite properly so, in most
cases). But in designing the configuration system, simplifying life
for *users* is just as important, if not more so. Sometimes this
implies not going as far in the direction you favor direction as you
might like (monolithic Configure.help is an example).
> 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 fragment, they have to touch a global file that they don't "own".
Yes, there are two reasons for this.
The contingent, historical reason is that I wanted to get
Configure.help in good shape before thinking about dispersing it.
That work is now done (though you haven't kept up to date with it).
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 easier for people to do and distribute translations of it.
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 question-string localizations for French. And
German. And Thai. And Ethiopian.
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
If I were to select a jack-booted group of fascists who are
perhaps as large a danger to American society as I could pick today,
I would pick BATF [the Bureau of Alcohol, Tobacco, and Firearms].
-- U.S. Representative John Dingell, 1980
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 the mdbm code, you can have a server process which
reads the data, stashes it in the db, touchs ./i_am_done, and exits.
"client" processes do a
while (!exists("i_am_done")) usleep(100000);
m = mdbm_open("db", O_RDONLY, 0, 0);
val = mdbm_fetch_str(m, "key");
etc.
No sockets, no back and forth, runs at mmap speed.
If you tell me what the data looks like that needs to be in the DB, i.e.,
how to get it, I'll code you up the "server" side.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
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 easier for people to do and distribute translations of it.
>
> 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 question-string localizations for French. And
> German. And Thai. And Ethiopian.
You are nuts. OK, you've got these translations. Now what? $FOO adds
a new option. Should he, by any chance, supply all relevant translations
in the same patch? No? Good, so we are going to have them permanently
out of sync. Better yet, option changes its meaning. Now we have
English variant with new semantics and Thai one with the old. Happy,
happy, joy, joy...
And that's aside of the real problem with "internationalization" - quality
of translations _sucks_. Always. Yes, USAnian to English is easy. But
that's it. I've tried to use LANG=ru_RU.koi8-r. It had lasted a couple
of days. You end up reconstructing the English original and translating
it to Russian - and boy, does that process annoy...
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 to deal with the resulting mess for real?
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.
>
> Actually, if you use the mdbm code, you can have a server process which
> reads the data, stashes it in the db, touchs ./i_am_done, and exits.
> "client" processes do a
>
> while (!exists("i_am_done")) usleep(100000);
> m = mdbm_open("db", O_RDONLY, 0, 0);
> val = mdbm_fetch_str(m, "key");
> etc.
>
> No sockets, no back and forth, runs at mmap speed.
That sounds like a better approach. I got a bit nervous when Keith
talked about a "server process". Made me think I'm going to have to
install some daemon, or I'm going to have a pile of background
processes being left behind (no matter how careful you are, you always
end up with some "leakage" of stale processes).
Regards,
Richard....
Permanent: [email protected]
Current: [email protected]
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 fragment, they have to touch a global file that they don't "own".
>
> 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
> (without the automatic checking and losing some information) from the
> information.
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.
Jeff
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
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 page split costs) and got it down to 105 millisecs from
200, so we're at 12 usecs per item. Then I removed the mdbm_store()
call so I was doing everything except that. That took 7 usecs/item.
Write path summary: the mdbm_store() cost is about 5 usecs/item, which
is about right. To build a DB of the same number of items as source
files in the kernel should cost less than 50 milliseconds for the DB
part of the work. In other words, it's basically free.
OK, on to the read path. I generated the list of inodes as an ascii file
and wrote another program to open the mdbm and fetch each one. Ran that
10 times, it cost 40 milliseconds to look up all the items, so that's
about 4 usecs/item including the read of the data from stdin. That's
slower than I think it should be and I may go look to see what is going
on, but it's plenty fast for the config/build system.
Here's the code. Sorry about the perlisms, wait, no I'm not, I like those,
but it will make you look at it twice before it makes sense.
------------------------------------------------------------------------------
/*
* inode.c - create an MDBM of inode -> path mappings
*/
#include <sys/types.h>
#include <sys/stat.h>
#include <sys/fcntl.h>
#include <stdio.h>
#include <unistd.h>
#include "mdbm.h"
#define unless(x) if (!(x))
#define fnext(buf, f) fgets(buf, sizeof(buf), f)
#define u32 unsigned int
void
chomp(char *s)
{
unless (s && *s) return;
while (*s && (*s != '\n')) s++;
*s = 0;
}
u32
inode(char *path)
{
struct stat sb;
if (lstat(path, &sb)) return (0);
return ((u32)sb.st_ino);
}
int
main()
{
char buf[1024];
MDBM *m;
datum k, v;
u32 ino;
unlink("ino.mdbm");
unless (m = mdbm_open("ino.mdbm", O_RDWR|O_CREAT, 0644, 4<<10)) {
perror("ino.mdbm");
exit(1);
}
mdbm_pre_split(m, 128);
while (fnext(buf, stdin)) {
chomp(buf);
unless (ino = inode(buf)) {
perror(buf);
continue;
}
printf("%u\n", ino);
k.dptr = (void*)&ino;
k.dsize = sizeof(u32);
v.dptr = buf;
v.dsize = strlen(buf) + 1;
if (mdbm_store(m, k, v, MDBM_INSERT)) {
perror(buf);
exit(1);
}
}
mdbm_close(m);
exit(0);
}
------------------------------------------------------------------------------
/*
* read.c - read items from the mdbm
*/
#include <sys/types.h>
#include <sys/stat.h>
#include <sys/fcntl.h>
#include <stdio.h>
#include <unistd.h>
#include "mdbm.h"
#define unless(x) if (!(x))
#define fnext(buf, f) fgets(buf, sizeof(buf), f)
#define u32 unsigned int
int
main()
{
char buf[1024];
MDBM *m;
datum k, v;
u32 ino;
unless (m = mdbm_open("ino.mdbm", O_RDONLY, 0644, 0)) {
perror("ino.mdbm");
exit(1);
}
while (fnext(buf, stdin)) {
ino = atoi(buf);
continue;
k.dptr = (void*)&ino;
k.dsize = sizeof(u32);
v = mdbm_fetch(m, k);
unless (v.dsize) {
perror(buf);
exit(1);
}
}
mdbm_close(m);
exit(0);
}
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 question-string localizations for French. And
> > German. And Thai. And Ethiopian.
>
> You are nuts. OK, you've got these translations. Now what? $FOO adds
> a new option. Should he, by any chance, supply all relevant translations
> in the same patch? No?
No. The usual way to handle this, of course, is to fall back on the English
where you don't have translations. Imperfect, but liveable.
> Good, so we are going to have them permanently
> out of sync. Better yet, option changes its meaning. Now we have
> English variant with new semantics and Thai one with the old. Happy,
> happy, joy, joy...
Which is why there are organized translation groups that do periodic
translation updates for software that has registered with them. This
doesn't eliminate the problem, but it can keep it within manageable bounds
that make having localizations better than not. I deal with this regularly
with respect to fetchmail.
Anyway, options change semantics only very rarely in the kernel rulebase.
Trust me on this as I've been maintaining the CML2 rulebase for 18 months;
I have a better handle on the frequency of these events than *anyone* else.
You are worrying about a non-problem in this case.
> And that's aside of the real problem with "internationalization" - quality
> of translations _sucks_. Always.
No, not always. I read French, Italian, and Spanish; I can puzzle out
technical prose in a couple of other languages. I can read
fetchmail's .po files and *see* that they don't suck.
> Frankly, I find it very amusing that advocates of i18n efforts tend to
> be either British or USAnians.
That's not my experience. I've had technical problems with GNU
gettext (unrelated to quality of translation) severe enough that I've
come very close to dropping localization support twice. The people
who plead with me not to drop it have been non-Anglophones.
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 have useful results.
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
I do not find in orthodox Christianity one redeeming feature.
-- Thomas Jefferson
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 nasty centralized knowledge in the MAINTAINERS and CREDITS
files) and was shot down.
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.
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
"Those who make peaceful revolution impossible
will make violent revolution inevitable."
-- John F. Kennedy
[So far, I've generally been trying to keep away from the hot topics, but
I guess it's about time to make that experience. Also, let me add that my
opinion here is of course influenced by the fact that things didn't go the
way I would have liked...]
On Fri, 28 Dec 2001, 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 inaccurate, kbuild 2.5 is slower but accurate.
> Pick one.
Most problems which exist within kbuild 2.4 are fixable without the
elaborate rewrite Keith did. The single biggest problem the current system
has is that modversions get screwed up, since dependencies are screwed up,
and yes, that's not easily fixable. However, this problem isn't even
attacked in kbuild 2.5 AFAIK (I think modversions are simply disabled
there).
A couple of months ago, I came up with an alternative to kbuild 2.5. It
doesn't try to have all the features kbuild 2.5 has, but solves the major
problems with kbuild 2.4. It definitely has things in common with kbuild
2.5, it also uses the "non-recursive" approach, i.e. the top level
Makefile includes all the others. It also doesn't have "make dep" but
builds dependencies with "gcc -MD" plus postprocessing.
I'm not claiming it is complete, and it doesn't even try to add the
multiple source tree etc. features. Others said one should use proper
version management instead, and I agree with that, but that's not the
point.
Non-complete list of pros/cons:
o gets dependencies right, i.e. a new make "whatever" will really rebuild
everything which is needed. Even *with* CONFIG_MODVERSIONS turned on.
o uses standard tools. I believe people said that one of the advantages
of UNIX is that you don't need specialized tools for everything, but
combine existing tools to reach your goals. The new kbuild has the
disadvantage that most is implemented from scratch, the meat is in C
programs which probably nobody apart from Keith is familiar with.
My solution used the standard tool for building, i.e. make + standard
utilities like sh, sed, grep and the like. I only have one non-standard
tool, that postprocesses a dependency list: replace
include/linux/autoconf.h with the /include/linux/config/options - this
is needed so that a .config change doesn't cause an entire rebuild
every time.
o It's actually pretty fast. On my laptop, the time to read all the
dependencies when doing a "make bzImage modules" is was about 5 seconds
with hot caches. That means a make takes about 5 seconds when there's
nothing to do - that's good enough IMHO. When
doing a full rebuild, the time spent within make is definitely down in
the noise, if only a few files get rebuild, it's noticable, but still
faster than what the current kbuild system gives.
o The Makefiles in the SUBDIRS look basically the same as currently, only
a somewhat simpler (no special $(LD) rules for composite objects etc).
Keith implemented a whole new language - I supoose most coders are
familiar with normal Makefiles, they have yet to learn the new commands in
kbuild-2.5 (which, however, is easy, of course)
o It's not nearly as feature-rich as Keith's approach is.
o Behind the scenes, the code is not exactly clear. make is pretty
flexible, but it really needs some hacks to do what's needed. So
if someone wants to understand the build system, it takes some effort -
same situation as in kbuild-2.4 and -2.5, though.
o I had the major problems solved and things worked fine in my tree.
However, I discontinued to work on it months ago, as I saw no way this
work would ever be useful for other people - maintaining a build system
just for personal use is a bit too much effort.
I don't claim that my work is superior to kbuild-2.5 or anything. (I still
think it may be "good enough", i.e. does solve the current problems - it
doesn't add features, though). But I'm dissatified that there never ever
was even consideration. When I posted ideas/patches to kbuild-devel, I
usually got a response like "this work isn't needed, I developed
kbuild-2.5, which will be the solution to all problems in 2.5". I also
submitted non-intrusive changes for 2.4, which fixed/simplified things
there without breaking anything, but the answer was about the same,
"kbuild-2.4 is obsolete, for 2.5 it's irrelevant". Well, 2.4 will be
around for some time I guess...
When I replied (with technical arguments), I never heard anything back -
compare the current thread about just silently dropping mails/patches
;-(
That's why I decided to drop out of the kbuild business again. (BTW: note
that this was about kbuild-2.5 only - nothing to do with CML2)
--Kai
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 purely make format) which includes 'ifdef CONFIG_xxx'
information embedded within. We know that make can support ifeq
CONFIG_xxx for example...
Jeff
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 proposed implementing something like this about a year ago (to
> replace the nasty centralized knowledge in the MAINTAINERS and CREDITS
> files) and was shot down.
Note I am specifically NOT talking about MAINTAINERS and CREDITS.
-PLEASE- don't obscure my point by mentioning them.
Dealing with MAINTAINERS and CREDITS in an automated fashion seems more
like pointless masturbation to me. If you want to find out who needs to
be CC'd on patches, use your brain like I do.
Jeff
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.
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
It will be of little avail to the people, that the laws are made by
men of their own choice, if the laws be so voluminous that they cannot
be read, or so incoherent that they cannot be understood; if they be
repealed or revised before they are promulgated, or undergo such
incessant changes that no man, who knows what the law is to-day, can
guess what it will be to-morrow. Law is defined to be a rule of
action; but how can that be a rule, which is little known, and less
fixed? -- James Madison, Federalist Papers 62
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, because I want to do "diffstat" on a patch from
a PPC maintainer, and if I see anything non-PPC, loud ringing
noises go off in my head. I want that diffstat to say _only_
arch/ppc/...
include/asm-ppc/...
and nothing else. That way I know that I don't have to worry.
In contrast, if it starts talking about Documentation/Configure.help and
the main config file, I start worrying.
For example, that MATHEMU thing is just ugly. It was perfectly fine in the
per-architecture version, now it suddenly has magic dependencies just
because different architectures call it different things, and different
architectures have different rules on when it's needed.
Linus
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 -name "*.cf" -exec cat {} \; > Configure.help
For old tools..
> or changing the tools to look for
>
> Documentation/Configure/CONFIG_SMALL_BANANA
"small banana"? Freud would go wild.
But no. I don't want it under the Documentation directory: I'd much rather
have them _together_ with the config file.
So the config file format could be something that includes the docs, and
you could do something like
find . -name '*.cf' -exec grep '^+' {} \; > Configure.help
for old tools, and nw tools would just automatically get the docs from the
same place they get the config info.
And there would _never_ be more than a few entries per config file: you
can imagine having a separate config file for PCI 100Mbps ethernet drivers
and one for ISA drivers.
The current Configure.help is 25k _lines_, and over a megabyte in size. I
would never consider that good taste in programming, why should I consider
it good in documentation?
Linus
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 _right_.
Linus
Linus Torvalds <[email protected]>:
> So the config file format could be something that includes the docs, and
> you could do something like
>
> find . -name '*.cf' -exec grep '^+' {} \; > Configure.help
>
> for old tools, and nw tools would just automatically get the docs from the
> same place they get the config info.
OK. Background, for anyone who doesn't know this: the equivalent of
Configure.help in CML2 is the symbols.cml file. It's actually generated
fat CML2 installation time from Configure.help.
Here's what a sample entry looks like in Configure.help form:
Support the foo feature
CONFIG_FOO
This is a sample help entry.
Here's the same entry in CML2 format:
FOO "Support the foo feature" text
This is a sample help entry.
.
Now. It would be dead easy to split symbols.cml into bunch of little
files and distribute them through the source tree. It would be just as
easy to write a script to reassemble Configure.help, but there won't be
any reason to do it. Once CML2 goes in, nothing will use Configure.help
> The current Configure.help is 25k _lines_, and over a megabyte in size. I
> would never consider that good taste in programming, why should I consider
> it good in documentation?
Um...because the cases aren't parallel?
What makes megabyte-large blocks of code bad is that they tend to be
tangled messes with unmaintainable reference and control structures.
Configure.help isn't; the entries are atoms that don't interact with
each other.
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
We shall not cease from exploration, and the end of all our exploring will be
to arrive where we started and know the place for the first time.
-- T.S. Eliot
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 credits information - people can put stuff in
there for their own (C) messages etc. The MAINTAINERS file is a much
higher-level thing which is there to be human-readable.
Note that I do _not_ want to mess up source files with magic comments. I
absolutely detest those. They only detract from the real job of coding,
and do not make anybody happier.
We have a hierarchical filesystem. Most drivers already have
driver.c
driver.h
(in fact _very_ few drivers are single-file) and some have a subdirectory
of their own. So why not just have
driver.conf
and be done with it. No point in messing up the C file with stuff that
doesn't add any information to either the programmer _or_ the compiler.
Then you can make the config file _truly_ readable, and make the format
something like
define tristate
CONFIG_SCSI_AIC7XXX: Adaptec AIC7xxx support
This driver supports all of Adaptec's PCI based SCSI controllers
(not the hardware RAID controllers though) as well as the aic7770
based EISA and VLB SCSI controllers (the 274x and 284x series).
This is an Adaptec sponsored driver written by Justin Gibbs. It is
intended to replace the previous aic7xxx driver maintained by Doug
Ledford since Doug is no longer maintaining that driver.
depends on CONFIG_SCSI
depends on CONFIG_PCI
depends on ...
define integer
CONFIG_AIC7XXX_CMDS_PER_DEVICE: Maximum number of TCQ commands per device
depends on CONFIG_SCSI_AIC7XXX
default value 253
define integer
CONFIG_AIC7XXX_RESET_DELAY_MS: Initial bus reset delay in milli-seconds
depends on CONFIG_SCSI_AIC7XXX
default value 15000
....
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.
Linus
On Fri, Dec 28, 2001 at 05:08:40PM -0500, Eric S. Raymond wrote:
> What makes megabyte-large blocks of code bad is that they tend to be
> tangled messes with unmaintainable reference and control structures.
> Configure.help isn't; the entries are atoms that don't interact with
> each other.
Doesn't this statement miss the point that the configure stuff belongs with
the associated source, for many reasons? Reasons being stuff like Linus'
desire to see PPC stuff only under the PPC directories, stuff like the
desire to have the config stuff as part of the source. The very fact
that they are atoms and don't interact with each seems to scream that they
should be located next to, or in, the stuff with which they do interact.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
On Fri, 28 Dec 2001, Eric S. Raymond wrote:
>
> OK. Background, for anyone who doesn't know this: the equivalent of
> Configure.help in CML2 is the symbols.cml file. It's actually generated
> fat CML2 installation time from Configure.help.
Oh, crap, _another_ magic global file.
Eric, this is the _wrong_approach_. I want /local/ files, not global ones.
Linus
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 is.
>
> It _is_ a problem for me, because I want to do "diffstat" on a patch from
> a PPC maintainer, and if I see anything non-PPC, loud ringing
> noises go off in my head. I want that diffstat to say _only_
>
> arch/ppc/...
> include/asm-ppc/...
>
> and nothing else. That way I know that I don't have to worry.
Perhaps we're talking past each other. I don't understand your objection
yet, and I want to so I can design (or redesign) to meet it.
When I talk about "rules that use architecture symbols to suppress
things like bus types" I have in mind things like this:
unless X86 suppress dependent MCA EISA
unless MIPS32 suppress dependent TC
unless (PCI and (X86 or SUPERH)) suppress pci_access
unless (ISA or PCI) suppress dependent IDE
unless PCI suppress dependent USB HOTPLUG_PCI
unless (X86 or ALPHA or MIPS32 or PPC) suppress usb
unless (X86 and PCI and EXPERIMENTAL) or PPC or ARM or SPARC suppress dependent IEEE1394
unless (M68K or ALL_PPC) suppress MACINTOSH_DRIVERS
unless SPARC suppress dependent FC4
unless ARCH_S390==n suppress buses
It seems to me *extremely* unlikely that a typical patch from a PPC maintainer
would mess with any of these! They're rules that are likely to be written
once at the time a new port is added to the tree and seldom or ever changed
afterwards.
Thus I really don't think you have to worry about spurious spikes in
your diffstat. The root rules.cml file will not change very often --
I know this is true, because I can look at the RCS history since I
broke it out in response to your request at the Kernel Summit and
*see* that changes have been few and sparse.
> In contrast, if it starts talking about Documentation/Configure.help and
> the main config file, I start worrying.
Rightly so in the latter case. Configure.help patches shouldn't worry
you, I don't think. It's not like they can actually break anything.
> For example, that MATHEMU thing is just ugly. It was perfectly fine in the
> per-architecture version, now it suddenly has magic dependencies just
> because different architectures call it different things, and different
> architectures have different rules on when it's needed.
It sounds to me like you're agreeing that it *shouldn't* be called
different things, and thus with my goal of cleaning this mess up the
rest of the way. Yes? No?
Guidance, please. I am, as ever, willing to meet your concerns.
But I have to understand clearly what they are in order to do that.
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
"...The Bill of Rights is a literal and absolute document. The First
Amendment doesn't say you have a right to speak out unless the
government has a 'compelling interest' in censoring the Internet. The
Second Amendment doesn't say you have the right to keep and bear arms
until some madman plants a bomb. The Fourth Amendment doesn't say you
have the right to be secure from search and seizure unless some FBI
agent thinks you fit the profile of a terrorist. The government has no
right to interfere with any of these freedoms under any circumstances."
-- Harry Browne, 1996 USA presidential candidate, Libertarian Party
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 builds to 100%
>>slower on a full kernel build.
>>
>
>I don't understand why it would be slower.
>
Thank's go to basically to python and other excessfull overengineering
there.
On Fri, Dec 28, 2001 at 09:56:53PM +0100, Kai Germaschewski wrote:
> A couple of months ago, I came up with an alternative to kbuild 2.5. It
> doesn't try to have all the features kbuild 2.5 has, but solves the major
> problems with kbuild 2.4.
So has anyone looked at this? Is this a viable choice? I've heard nothing
since Kai posted this. Keith?
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
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 simpler solution to this: have the
>core dependency files generated from some other file format.
>
>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 architecture-specific info, for example?
>
>That's a big step backwards as far as I'm concerned - we didn't use to
>have those stupid global files, and each architecture could do it's own
>config rules. Eric never got the point that to me, modularity is _the_
>most important thing for maintenance.
>
>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 fragment, they have to touch a global file that they don't "own".
>
>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
>(without the automatic checking and losing some information) from the
>information.
>
If you go thus far... then I think, that the Configure.help stuff should
be embedded inside the driver source code
itself. Like for example the postfix MTA code is embedding whole *man*
pages there. And *man* pages would be
anyway a more appriopriate and classical place where the current
Configure.help information should be.
Just lift the code over from there (The extraction is even proper awk
insead of some perl crap...) and be nearly done.
> 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 already rip out
code comments via kernel-doc, and extending it to rip out
- Help text
- Web site
- Version information
- Man page for the driver
- Module options
etc, shouldn't be too challenging. Ok so kernel-doc is in perl and ugly perl
but if someone hates it enough to rewrite it in python thats a win too 8)
Alan
> 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 to deal with the resulting mess for real?
The biggest advocates I see are from the Middle-East and Japan. We already
have people providing translations for Configure.help in several languages.
Alan
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).
Something like:
/* mydriver.c .... header blah blah */
config_requires(CONFIG_INET);
config_option(CONFIG_MY_FAST_CHIP, "Help info for this");
which gets picked out of the .c files during depend phase, and nullified
during compile by means of -Iconfig_system.h would even let us get rid of
Makefiles for drivers. Wouldn't being able to just drop a .c file (or a
bunch of .c files) into the tree in the right place be great? Eliminating
makefiles means eliminating more conflicts, which might mean more time to
respond to other issues...
-ben
--
Fish.
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, whether ripped out or
not.
Extra stuff is not helpful to anybody, and is just really irritating. I
personally despise source trees that start out with one page of copyright
statement crap, it just detracts from the real _point_ of the .c file,
which is to contain C code. Making it a comment requirement is
- stupid:
we have a filesystem, guys
- slow:
we don't need to parse every C file we encounter when we can just
open another file based on filename
- nonsensical:
many config options are _not_ limited to one C file
- hard to parse and read:
why limit ourself to C comments, when just keeping the thing
logically separated means that we don't have to.
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.
_None_ of those are sensible for config file entries.
Linus
Martin Dalecki <[email protected]>:
> >>At the moment kbuild 2.5 ranges from 10% faster on small builds to 100%
> >>slower on a full kernel build.
> >
> >I don't understand why it would be slower.
> >
> Thank's go to basically to python and other excessfull overengineering
> there.
Bzzzt! Thank you for playing.
kbuild-2.5 doesn't use Python.
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
The possession of arms by the people is the ultimate warrant
that government governs only with the consent of the governed.
-- Jeff Snyder
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 important question. Right now, most options are low-level
and platform-specific, which makes it easy to decide what directory
their symbol declaration(s) should live in. But that's not good;
there are lots of excellent reasons we want there to be *more*
cross-platform capability symbols rather than fewer. So the
percentage of "roving" symbols without an obvious home is likely
to go up over time.)
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.)
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 logical time to split up symbols.cml would be immediately after
CML2 goes into the tree, because at that point Configure.help won't
be an issue any more.)
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.
So, I can and will put this in the transition plan if that's what you
direct. But you need to be aware that it's not a snap-of-the-fingers
change, and not something best done before CML1 goes away.
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
"As to the species of exercise, I advise the gun. While this gives [only]
moderate exercise to the body, it gives boldness, enterprise, and independence
to the mind. Games played with the ball and others of that nature, are too
violent for the body and stamp no character on the mind. Let your gun,
therefore, be the constant companion to your walks."
-- Thomas Jefferson, writing to his teenaged nephew.
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 things out enough - why does
> the
> main "rules.cml" file have architecture-specific info, for example?
agreed - it's something that really irritates me too. As Linux is
running on so many different architectures (some of which are purely
virtual, such as Usermode Linux and my whacky idea of running it ontop
of MacOS X) so it seems that keeping all the options for architectures
separate would make a lot of sense. I've never seen a cross-platform
binary kernel (although have had scary dreams of one)
<snip>
> 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
> (without the automatic checking and losing some information) from the
> information.
This shouldn't be too hard should it? In each module directory have a
config and Configure.help file, then just
find . |grep config
and then cat all the files together. If I have some spare time today
I'll see if I can hack something up.... :)
------------------------------
Stewart Smith
[email protected]
Ph: +61 4 3884 4332
ICQ: 6734154
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 already rip out
> code comments via kernel-doc, and extending it to rip out
>
> - Help text
> - Web site
> - Version information
> - Man page for the driver
> - Module options
>
> etc, shouldn't be too challenging. Ok so kernel-doc is in perl and ugly perl
> but if someone hates it enough to rewrite it in python thats a win too 8)
I've been thinking about doing that very thing anyway. Part of my master
plan to reduce the tree's external dependencies.
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
I do not find in orthodox Christianity one redeeming feature.
-- Thomas Jefferson
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 to programmers, whether ripped out or
>not.
>
>Extra stuff is not helpful to anybody, and is just really irritating. I
>personally despise source trees that start out with one page of copyright
>statement crap, it just detracts from the real _point_ of the .c file,
>which is to contain C code. Making it a comment requirement is
>
> - stupid:
> we have a filesystem, guys
>
Not quite... It is making moving patches through e-mail around easier...
>
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 it doesn't get this part
> right. "mkdep.c" gets this _right_.
Well, -MD gets this right. The dependencies it generates will cause a
recompile when necessary. Unfortunately, though, it's too good, because
the dependency on include/linux/autoconf.h will cause lots of unnecessary
recompiles.
But yes, it seems possible to replace the -MD dependency file, which
depends on a specific config, with a generic dependency file, which knows
about our #ifdef CONFIG_XXX and translates them to the corresponding
ifeq(CONFIG_,) Makefile syntax. It'd make an interesting project, but it
effectively means re-implementing a C preprocessor.
I don't think you can blame gcc -MD for not knowing about the kernel's
CONFIG_ system, though ;-)
From
---
#ifdef CONFIG_XXX
#include <linux/xxx.h>
#endif
#ifdef CONFIG_YYY
const int nr = 10;
#else
const int nr = 100;
#endif
---
you'd have to generate
---
ifeq(CONFIG_XXX,y)
DEPS += include/linux/xxx.h
endif
DEPS += include/config/yyy
---
i.e. the include/config trick has to stay any way.
I don't think the above is necessary, though, the following does work
pretty good (I did it this way, inspired by mec, and I think kbuild-2.5
does it similarly):
Generate dependencies for a .o file when compiling it.
[ Doing make dep in advance is unnessary. Actually, it's pretty stupid to
generate dependencies for *all* possible object files which you are never
going to compile (think arch/*). If you don't have the object yet, you
don't need to know the dependencies, dependencies only make sense for
recompiles. It's also cheaper to generate dependencies during the compile,
as you need to read the file anyway. Also, dependencies on generated files
cannot be found correctly until these files have been generated. ]
The generated dependencies will always include linux/autoconf.h, which is
correct, but will cause too many recompiles. So, replace linux/autoconf.h
with linux/config/xxx, where xxx are all the config options which appear
in all of the files used to build the object file (which is what -MD gave
you).
The result is still dependencies which are 100% correct. It's that simple.
The object file gcc generates depends on the command line and all the
files it reads during the compile. Why make it more complex?
--Kai
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
>> involved means faster conversion from absolute to standardized names.
>
>Actually, if you use the mdbm code, you can have a server process which
>reads the data, stashes it in the db, touchs ./i_am_done, and exits.
>"client" processes do a
>
> while (!exists("i_am_done")) usleep(100000);
> m = mdbm_open("db", O_RDONLY, 0, 0);
> val = mdbm_fetch_str(m, "key");
> etc.
>
>No sockets, no back and forth, runs at mmap speed.
>
>If you tell me what the data looks like that needs to be in the DB, i.e.,
>how to get it, I'll code you up the "server" side.
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 talk to that server. Otherwise each compile will
have overhead for lock, open, mmap, update, close, write back, unlock.
A single threading server removes the need for lock/unlock and can sync
the data to disk after n compiles instead of being forced to do it
after every compile.
If your experience says that doing updates from each compile step
without a server process would not be too slow, let me know.
> 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 talk to that server. Otherwise each compile will
> have overhead for lock, open, mmap, update, close, write back, unlock.
> A single threading server removes the need for lock/unlock and can sync
> the data to disk after n compiles instead of being forced to do it
> after every compile.
>
> If your experience says that doing updates from each compile step
> without a server process would not be too slow, let me know.
You certainly don't need a server process. And as was pointed out
earlier, it's nice not to have them, then you don't have to worry
about them still being there.
I can write you up a multi writer version using in file locks (which
work over NFS, we had do that for BK and I'm pretty sure it is platform
independent, I can't break it). We have to do this sort of multi
reader/writer crud in BK all the time and have lots of experience with
locking, breaking locks, waiting, NFS, etc. Much more experience than
we ever wanted :-)
You don't need to sync to disk at all, let the data sit in memory, that's
why mmap is cool.
Give me a spec for what you want, I'll crank out some code. Maybe I'll
finally actually be useful to the kernel after all these years...
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
On Fri, Dec 28, 2001 at 06:05:57PM -0500, Benjamin LaHaise wrote:
> 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).
> Something like:
>
> /* mydriver.c .... header blah blah */
> config_requires(CONFIG_INET);
> config_option(CONFIG_MY_FAST_CHIP, "Help info for this");
If Linus is willing to buy into "driver.conf" there is no need to stuff
things into the source. [my previous post made the mistaken assumption
that Linus would not like an additional metadata file like driver.conf]
A per-driver metadata file is IMHO clearly the preferred solution.
Jeff
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
>releases a tarball. This in turn generates dependency information
>(perhaps not in purely make format) which includes 'ifdef CONFIG_xxx'
>information embedded within. We know that make can support ifeq
>CONFIG_xxx for example...
Then people apply patches and break. Please read the list of mkdep
bugs before suggesting partial fixes.
http://prdownloads.sourceforge.net/kbuild/kbuild-2.5-history.tar.bz2,
makefile-2.5_make_dep.html. I want a system that fixes _all_ the bugs,
not just some of them.
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 detest "gcc -MD", exactly because it doesn't get this part
>right. "mkdep.c" gets this _right_.
Sorry, it does not. Everybody is attacking little bits of the
dependency problem, any solution that does not fix _all_ 9 problems in
http://prdownloads.sourceforge.net/kbuild/kbuild-2.5-history.tar.bz2,
makefile-2.5_make_dep.html is not a complete fix.
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! Please do not say "I always run make
dep" after a change, I guarantee that you are the exception. Users
apply patches and do not run make dep, then wonder why their kernel is
broken.
Dependencies _do_ change when your .config changes, the list of files
that are included varies. gcc -MD gets this exactly right, gcc knows
which files it read. mkdep does an incorrect approximation, see tyhe
bug list in makefile-2.5_make_dep.html.
The errors in mkdep were acceptable as long as only kernel hackers
built their own kernels, they could be relied upon to manually run
commands when necessary. The target population has changed, more and
more beginners are building kernels and too many are getting it wrong.
I am aiming at the entire population, not that small subset who have
been building kernels since the year dot.
Any build system that silently fails when users forget to run a command
is a broken system. kbuild 2.5 fixes _all_ 9 problems with mkdep, it
also positions us for correct modversion handling. kbuild 2.4 is
faster, inaccurate and manual, kbuild 2.5 is slower, accurate and
totally automatic.
I know how to speed up 2.5. What I don't have is time to rewrite the
code for speed, I am too busy tracking kernel changes because kbuild
2.5 is not in the kernel yet.
Linus, you have a choice between a known broken build system and a
clean and reliable system, which is slightly slower in mark 1. Please
add kbuild 2.5 to the kernel, then I will have time to rewrite the core
programs for speed. Mark 2 of the core code will be significantly
faster.
ps. I don't want mail discussing individual bug fixes to mkdep. Code
that does not fix _all_ 9 bugs listed in makefile-2.5_make_dep.html
is pointless.
> dependency problem, any solution that does not fix _all_ 9 problems in
> http://prdownloads.sourceforge.net/kbuild/kbuild-2.5-history.tar.bz2,
> makefile-2.5_make_dep.html is not a complete fix.
All well and good but "takes 100% longer" is number 10 on that list which
you missed off, and the same argument holds for that.
> 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! Please do not say "I always run make
So automate running make dep.
> Linus, you have a choice between a known broken build system and a
So broken its worked for say 5 years without major problem
> ps. I don't want mail discussing individual bug fixes to mkdep. Code
> that does not fix _all_ 9 bugs listed in makefile-2.5_make_dep.html
> is pointless.
And bug number 10 you didnt mention
On Fri, 28 Dec 2001 17:39:08 +0000 (GMT),
Alan Cox <[email protected]> wrote:
>> * make dep is only run once
>>
>> Personally, I don't see this as a big problem. Just tell people to
>
>I run make dep whenever I change config. Guess what - one cmp and I can
>automate that as part of make. If the .config doesnt match the
>.configwhendep then its time to make dep again
Don't forget that any change that affects a file's #include list
(including patches) requires you to run make dep.
make dep does not handle generated files at all, change the code that
generates a file and the file is regenerated but make dep did not pick
up the file the first time so kbuild 2.4 does not detect the change.
Another make dep will fix that of course. So now we have
Run make dep after -
A change to .config.
Any source change, it might have changed the #include list.
Any source or command line change that affects generated files.
How do you automate that? You end up saying that you always run make
dep.
>> That dependencies are absolute is also not a thing that has bothered me
>> too much, it's always possible to run "make dep" after moving a tree,
>> on the other hand, I don't use NFS a lot anymore, so I can see it being
>> a problem in other environments.
>
>sed works too, as do symlinks
For people who know what they are doing, not for the larger population
that are struggling with the kernel build process. kbuild 2.5 is
designed to work accurately and automatically for everyone, from the
high druids of the kernel down to the lowliest newbie.
> 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
problems with that.
Alan
On Sat, 29 Dec 2001 01:53:17 +0000 (GMT),
Alan Cox <[email protected]> wrote:
>> dependency problem, any solution that does not fix _all_ 9 problems in
>> http://prdownloads.sourceforge.net/kbuild/kbuild-2.5-history.tar.bz2,
>> makefile-2.5_make_dep.html is not a complete fix.
>
>All well and good but "takes 100% longer" is number 10 on that list which
>you missed off, and the same argument holds for that.
You are missing the point Alan.
* The makefile rules are correct now.
* The build is correct now.
* kbuild 2.5 is faster on small compiles and much faster on recompiles
after small changes.
* kbuild 2.5 is slower on large compiles.
* The speed problem is fixable, given time. Correctness came first.
* I don't have time to keep tracking multiple kernels and architectures
_and_ rewrite the core code.
* Once kbuild 2.5 is in the kernel I can spend far less time on
tracking changes and can redesign the core programs for speed.
* It will get faster!
Why do you expect a change in a development kernel to be perfect first
time? Look at all the bio changes, I just did a full 2.5.1 build and
had to disable 87 config options before the kernel would build, and
that is ignoring all the warning messages which point to out of date
function definitions. Is anybody complaining that bio should have
worked first time?
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.
On Fri, 28 Dec 2001 14:51:13 -0800,
Larry McVoy <[email protected]> wrote:
>On Fri, Dec 28, 2001 at 09:56:53PM +0100, Kai Germaschewski wrote:
>> A couple of months ago, I came up with an alternative to kbuild 2.5. It
>> doesn't try to have all the features kbuild 2.5 has, but solves the major
>> problems with kbuild 2.4.
>
>So has anyone looked at this? Is this a viable choice? I've heard nothing
>since Kai posted this. Keith?
I looked back through the kbuild mail for Kai's suggestions, I may not
have them all.
RFD: Tracking indirect dependencies [long]
We knocked this back and forth for a while. We both agree that
extracting dependencies after compile is correct, where we differed
was the mechanism. In fact I have currently implemented Kai's
approach (lots of little files) as a stepping stone to storing the
data in a database. It turns out that one of the reasons that kbuild
2.5 is slow is handling all the little files containing dependency
data.
[PATCH] removal of list-multi
I agree with the patch but that was December 2000, in code freeze,
and again in April 2001, AFAICR Linus had said "2.5 soon". This
patch is worth resurrecting for 2.4.
Auto detection of changed commands/flags
That was a decent fix for part of the problem, but it did not address
tracking user commands nor host compiles. It did not allow for
separate source and object trees, for read only source trees, nor did
it handle the more esoteric cases like modules being built from
multiple directories.
I am not interested in partial fixes, I want the whole kbuild problem
list to be cleared. Fixes that only solve part of the problem tend to
be filed and ignored.
Kai, did I miss any of your patches?
On Fri, 28 Dec 2001 14:27:37 -0800 (PST),
Linus Torvalds <[email protected]> wrote:
>Note that I do _not_ want to mess up source files with magic comments. I
>absolutely detest those. They only detract from the real job of coding,
>and do not make anybody happier.
>
>We have a hierarchical filesystem. Most drivers already have
>
> driver.c
> driver.h
>
>(in fact _very_ few drivers are single-file) and some have a subdirectory
>of their own. So why not just have
>
> driver.conf
>
>and be done with it. No point in messing up the C file with stuff that
>doesn't add any information to either the programmer _or_ the compiler.
I would love to do that, with each driver/filesystem/... having an
associated control file that defined its config options, its help and
who to make it. That is, an "Insert New Facility" file, we could call
them driver.inf (ducks and runs ;).
There is one big problem in the way, makefile order controls link order
which controls init order. I have no problem with the link order
controlling init order, that is far better than the old Space.c code.
I intensely dislike makefile order controlling link order, it results
in loss of information, we have makefiles in a specific order with no
idea about whether that order is required or is just accidental.
IMHO the link order should be divorced from makefile order and made
explicit. Then you could have makefile fragments associated with each
driver. But the last time I tried to break the dependency between make
and link order, Linus shot me down in flames[1], so I have no intention
of going there again. As long as you have monolithic makefiles,
drivers.conf is going to be problematic.
[1] http://marc.theaimsgroup.com/?l=linux-kernel&m=97301359812683&w=2
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.
> >
> >What about a system where Linus runs "make deps" -once- before he
> >releases a tarball. This in turn generates dependency information
> >(perhaps not in purely make format) which includes 'ifdef CONFIG_xxx'
> >information embedded within. We know that make can support ifeq
> >CONFIG_xxx for example...
>
> Then people apply patches and break.
s/break/update dependencies/
I assumed this was blindingly obvious, but I guess not.
Jeff
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 without regenerating all dependencies.
> Linus, you have a choice between a known broken build system and a
> clean and reliable system, which is slightly slower in mark 1. Please
> add kbuild 2.5 to the kernel,
Your system is known broken because it is 100% slower.
My kernel builds work just fine now, your changes gain me nothing,
while COSTING me productivity. I see no gains, only costs, with your
kbuild-2.5 system as it exists.
Keith the target audience is Linus and Alan and ME etc. We are the
kernel hackers that perform kernel -development-. Making end-user
builds easier is NOT a primary nor secondary nor tertiary goal here.
Make my life easier first. Fuck Aunt Tillie. Aunt Tillie can get
her kernels from a vendor.
Jeff
On Sat, Dec 29, 2001 at 12:44:00PM +1100, Keith Owens wrote:
> For people who know what they are doing, not for the larger population
> that are struggling with the kernel build process. kbuild 2.5 is
> designed to work accurately and automatically for everyone, from the
> high druids of the kernel down to the lowliest newbie.
Kernel building is not for newbies.
I'm all for lowering the barrier of entry until it affects the
productivity of people actually hacking on the code.
Jeff
On Fri, Dec 28, 2001 at 10:58:03PM -0500, Legacy Fishtank wrote:
> s/break/update dependencies/
>
> I assumed this was blindingly obvious, but I guess not.
To YOU and other kernel hackers, yes.
But not to everyone.
Plus, as I understand it, it will be faster to:
apply a patch and rebuild with kbuild 2.5
than to:
apply a patch, make dep && make bzImage.
Correct?
mrc
--
Mike Castle [email protected] http://www.netcom.com/~dalgoda/
We are all of us living in the shadow of Manhattan. -- Watchmen
fatal ("You are in a maze of twisty compiler features, all different"); -- gcc
On Fri, 28 Dec 2001 20:21:39 -0800,
Mike Castle <[email protected]> wrote:
>On Fri, Dec 28, 2001 at 10:58:03PM -0500, Legacy Fishtank wrote:
>> s/break/update dependencies/
>>
>> I assumed this was blindingly obvious, but I guess not.
>
>To YOU and other kernel hackers, yes.
>
>But not to everyone.
>
>Plus, as I understand it, it will be faster to:
>
>apply a patch and rebuild with kbuild 2.5
>
>than to:
>
>apply a patch, make dep && make bzImage.
>
>Correct?
As long as the patch does not change an include file that is used a
lot, yes, a patch and make will be significantly faster using kbuild
2.5.
What Mr. Fishtank seems to overlook is that kbuild 2.5 is far more
flexible and accurate than 2.4, including features that lots of people
want, like separate source and object trees. Now that the overall
kbuild design is correct, the core code can be rewritten for speed.
And that will be done a couple of weeks after kbuild 2.5 goes into the
kernel, then I expect kbuild 2.5 to be faster than kbuild 2.4 even on
full builds.
Em Sat, Dec 29, 2001 at 03:44:10PM +1100, Keith Owens escreveu:
> On Fri, 28 Dec 2001 20:21:39 -0800,
> Mike Castle <[email protected]> wrote:
> >On Fri, Dec 28, 2001 at 10:58:03PM -0500, Legacy Fishtank wrote:
> >> s/break/update dependencies/
> >>
> >> I assumed this was blindingly obvious, but I guess not.
> >
> >To YOU and other kernel hackers, yes.
> >
> >But not to everyone.
> >
> >Plus, as I understand it, it will be faster to:
> >
> >apply a patch and rebuild with kbuild 2.5
> >
> >than to:
> >
> >apply a patch, make dep && make bzImage.
> >
> >Correct?
>
> As long as the patch does not change an include file that is used a
> lot, yes, a patch and make will be significantly faster using kbuild
And thats something I encourage people to work on: to reduce the includes
dependencies hell, I hope to have the cleanup I did to include/net/sock.h
removing the protocol specific headers from there and the cleanup that
Daniel Phillips is doing in include/net/fs.h in the tree soon, of course if
there's not issues, that we're very interesting to know.
- Arnaldo
On Friday 28 December 2001 08:44 pm, Keith Owens wrote:
> On Fri, 28 Dec 2001 20:21:39 -0800,
>
> Mike Castle <[email protected]> wrote:
> >On Fri, Dec 28, 2001 at 10:58:03PM -0500, Legacy Fishtank wrote:
> >> s/break/update dependencies/
> >>
> >> I assumed this was blindingly obvious, but I guess not.
> >
> >To YOU and other kernel hackers, yes.
> >
> >But not to everyone.
> >
> >Plus, as I understand it, it will be faster to:
> >
> >apply a patch and rebuild with kbuild 2.5
> >
> >than to:
> >
> >apply a patch, make dep && make bzImage.
> >
> >Correct?
>
> As long as the patch does not change an include file that is used a
> lot, yes, a patch and make will be significantly faster using kbuild
> 2.5.
>
> What Mr. Fishtank seems to overlook is that kbuild 2.5 is far more
> flexible and accurate than 2.4, including features that lots of
> people want, like separate source and object trees. Now that the
> overall kbuild design is correct, the core code can be rewritten for
> speed. And that will be done a couple of weeks after kbuild 2.5 goes
> into the kernel, then I expect kbuild 2.5 to be faster than kbuild
> 2.4 even on full builds.
>
What, exactly, is the point of merging something that nobody is going
to use unless they want to test it, in which case they can grab a patch
from somewhere?
It's half the speed of the current system. The current system works, no
matter how horrible its internals can be. That makes the NEW system
BROKEN. If it's KNOWN to be BROKEN prior to merge then it shouldn't
even be in a 2.5.*-pre#.
kbuild 2.4 works, but it's ugly! Let's create a new system!
You mean the new system is half the speed but it's more attractive?
Well I guess we'll go with the new system anyway!
(sound familier?:
Oh look at this new processor with all this fancy shit from <company
name withheld>! It even scales to absurdly high Mhz numbers!
Let's all spend a ton of money to get it!
Oh wait, you mean this old processor that costs nothing compared to the
new one outperforms this new one? Oh well, let's get the new one anway!)
On Fri, 2001-12-28 at 22:59, Nicholas Knight wrote:
<snip>
> > What Mr. Fishtank seems to overlook is that kbuild 2.5 is far more
> > flexible and accurate than 2.4, including features that lots of
> > people want, like separate source and object trees. Now that the
> > overall kbuild design is correct, the core code can be rewritten for
> > speed. And that will be done a couple of weeks after kbuild 2.5 goes
> > into the kernel, then I expect kbuild 2.5 to be faster than kbuild
> > 2.4 even on full builds.
> >
>
> What, exactly, is the point of merging something that nobody is going
> to use unless they want to test it, in which case they can grab a patch
> from somewhere?
You don't seem to be reading Keith's message.
The point of merging is that Keith needs time to fix the
performance problem. Plus, additional testing would probably
be helpful.
> It's half the speed of the current system. The current system works, no
> matter how horrible its internals can be. That makes the NEW system
> BROKEN.
No, it's known to be slow in some circumstances.
> If it's KNOWN to be BROKEN prior to merge then it shouldn't
> even be in a 2.5.*-pre#.
Uh, many drivers cannot be built in the current 2.5 tree.
Temporary brokenness is acceptable in the development tree.
It is meant to be _unstable_. I recall periods when the
2.3 kernel was corrupting data for many users. This period
lasted about a week, IIRC. The kbuild 2.5 system will slow
people down, but not hose their development system installations.
I personally think two weeks of working at a slower pace is
an acceptable trade-off for the longterm benefits that Keith
has mentioned. It seems odd that several people in this
discussion seem to have ignored the repeated statements that
Keith will have little time for dealing with the performance
rewrite until the multiple kernel tree synchronization
time sink goes away. Telling Keith that he needs to go on
spinning his wheels while he cannot find time to deal with
the problem you are asking him to fix seems sort of unhelpful.
Perhaps you'd be willing to assist him in the rewrite?
Miles
On Sat, Dec 29, 2001 at 03:44:10PM +1100, Keith Owens wrote:
> What Mr. Fishtank seems to overlook is that kbuild 2.5 is far more
> flexible and accurate than 2.4, including features that lots of people
> want, like separate source and object trees.
I don't see the masses, or, well, anybody on lkml, clamoring for this.
IIRC from the kernel summit SGI was the only entity clamoring for this.
> Now that the overall
> kbuild design is correct, the core code can be rewritten for speed.
> And that will be done a couple of weeks after kbuild 2.5 goes into the
> kernel, then I expect kbuild 2.5 to be faster than kbuild 2.4 even on
> full builds.
Ok... you want kbuild into 2.5 ASAP, only to submit a rewrite two weeks later?
If so it makes even less sense to get kbuild into 2.5.x now.
Jeff
On Friday 28 December 2001 11:42 pm, Miles Lane wrote:
> On Fri, 2001-12-28 at 22:59, Nicholas Knight wrote:
>
> <snip>
>
> > > What Mr. Fishtank seems to overlook is that kbuild 2.5 is far
> > > more flexible and accurate than 2.4, including features that lots
> > > of people want, like separate source and object trees. Now that
> > > the overall kbuild design is correct, the core code can be
> > > rewritten for speed. And that will be done a couple of weeks
> > > after kbuild 2.5 goes into the kernel, then I expect kbuild 2.5
> > > to be faster than kbuild 2.4 even on full builds.
> >
> > What, exactly, is the point of merging something that nobody is
> > going to use unless they want to test it, in which case they can
> > grab a patch from somewhere?
>
> You don't seem to be reading Keith's message.
>
> The point of merging is that Keith needs time to fix the
> performance problem. Plus, additional testing would probably
> be helpful.
The performance problem is fixed by a rewrite, which will be done
shortly after its merge, thus, what is the point of merging now? You
don't seem to be reading either my message nor Keith's.
>
> > It's half the speed of the current system. The current system
> > works, no matter how horrible its internals can be. That makes the
> > NEW system BROKEN.
>
> No, it's known to be slow in some circumstances.
>
> > If it's KNOWN to be BROKEN prior to merge then it shouldn't
> > even be in a 2.5.*-pre#.
>
> Uh, many drivers cannot be built in the current 2.5 tree.
> Temporary brokenness is acceptable in the development tree.
Oh? Those drivers that cannot be built are a consequence of early work
to get something ELSE working.
Merging kbuild 2.5 is not *neccisary* to get anything else working in
2.5, thus so long as it's broken, it should not be merged. What is so
hard to understand about this?
> It is meant to be _unstable_. I recall periods when the
> 2.3 kernel was corrupting data for many users. This period
> lasted about a week, IIRC. The kbuild 2.5 system will slow
I don't recall there being any intention to cause corruption. There is
clearly intent here to merge something that shouldn't be.
> people down, but not hose their development system installations.
> I personally think two weeks of working at a slower pace is
> an acceptable trade-off for the longterm benefits that Keith
> has mentioned.
So, it's acceptable to annoy developers and 2.5 testers for two weeks
because a bad decision was made with full knowledge of the consequences?
> It seems odd that several people in this
> discussion seem to have ignored the repeated statements that
> Keith will have little time for dealing with the performance
> rewrite until the multiple kernel tree synchronization
> time sink goes away.
Make it go away. This is intended to first be used in 2.5, right? So
concentraite on getting it WORKING in 2.5, THEN worry about
backporting. kbuild 2.4 works for 2.4, kbuild 2.5 does not need to be
maintained for 2.4 now that 2.5 is up. Make it work in 2.5, then worry
about backporting it. (is there an echo in here?)
> Telling Keith that he needs to go on
> spinning his wheels while he cannot find time to deal with
> the problem you are asking him to fix seems sort of unhelpful.
If he can't find time to fix his own project, it's not my fault, nor is
it the fault of any kernel developer that he will be irritating the
shit out of with both the merging and the subsequent problems.
> Perhaps you'd be willing to assist him in the rewrite?
Sure, first you'll need to make me a pro at the language(s) in use.
I've stated repeatedly that I am not a developer for the Linux kernel.
I'm an annoying guy that tries to give the developers an occasional
reality check, which usualy fails.
BTW, Jeff Garzik (Legacy Fishtank) just said practicaly the same thing
I'm saying, why don't you go flame him now?
On Sat, Dec 29, 2001 at 12:02:07AM -0800, Nicholas Knight wrote:
> The performance problem is fixed by a rewrite, which will be done
> shortly after its merge, thus, what is the point of merging now? You
> don't seem to be reading either my message nor Keith's.
Did you catch the point, mentioned several times, that Keith needs to be
relieved of the duty of constantly re-syncing the the patch so that he has
time to do the rewrite.
That is the point of merging now.
Otherwise you'll never get the speed-up you're whining about.
mrc
--
Mike Castle [email protected] http://www.netcom.com/~dalgoda/
We are all of us living in the shadow of Manhattan. -- Watchmen
fatal ("You are in a maze of twisty compiler features, all different"); -- gcc
Legacy Fishtank wrote:
>
> On Sat, Dec 29, 2001 at 03:44:10PM +1100, Keith Owens wrote:
> > What Mr. Fishtank seems to overlook is that kbuild 2.5 is far more
> > flexible and accurate than 2.4, including features that lots of people
> > want, like separate source and object trees.
>
> I don't see the masses, or, well, anybody on lkml, clamoring for this.
Clamour.
The current system has some significant problems. Pet peeves:
- Failure to rebuild the right things after you've applied a patch
- Doesn't work when the same tree is accessed via different paths
(make dep on local machine, build across nfs)
- Mysterious recompilation of things which you've already compiled.
> IIRC from the kernel summit SGI was the only entity clamoring for this.
>
> > Now that the overall
> > kbuild design is correct, the core code can be rewritten for speed.
> > And that will be done a couple of weeks after kbuild 2.5 goes into the
> > kernel, then I expect kbuild 2.5 to be faster than kbuild 2.4 even on
> > full builds.
>
> Ok... you want kbuild into 2.5 ASAP, only to submit a rewrite two weeks later?
An optimisation of one bit, Keith says. I'd guess that his two-week
estimate is optimistic because he'll have a busy two weeks supporting
the patch once it goes in, but whatever.
> If so it makes even less sense to get kbuild into 2.5.x now.
Keith says it speeds up builds where only a small number of files
have changed. For me, that's the common case.
I'd like to hear more from Keith on where this 100% actually occurs,
but if he says it's fixable in a (give him four) week timeframe,
I believe him.
As you know, I'd be more concerned about moves to drop support
for the older and much faster gcc versions. If you're not using
egcs-1.1.2, you're already a very patient person.
> Jeff
Fish.
-
"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).
On December 29, 2001 09:13 am, Andrew Morton wrote:
> Legacy Fishtank wrote:
> >
> > On Sat, Dec 29, 2001 at 03:44:10PM +1100, Keith Owens wrote:
> > > What Mr. Fishtank seems to overlook is that kbuild 2.5 is far more
> > > flexible and accurate than 2.4, including features that lots of people
> > > want, like separate source and object trees.
> >
> > I don't see the masses, or, well, anybody on lkml, clamoring for this.
>
> Clamour.
Clamour.
Broke my tree yesterday, rm -rf was the fastest/easiest way out.
Immediately after make -j2 bzImage, make bzImage seems to rebuild about half
the tree.
Many incidents of time-wasting breakage over the last couple of years for me.
> Keith says it speeds up builds where only a small number of files
> have changed. For me, that's the common case.
Ooh, yes!
> I'd like to hear more from Keith on where this 100% actually occurs,
> but if he says it's fixable in a (give him four) week timeframe,
> I believe him.
He said something about reloading dependencies on each compile.
--
Daniel
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 simple, only recently growing over 1024 lines.
Anton
Ola, estava a descarregar os meus e-mails da Kernel mailing list e nao pude
deixar de repara no teu nome Portugu?s !!!!
E sempre bom saber que ha portugueses nestas andan?as e dispostos a ajudar.
Bem eu tenho dois problemas que quanto a mim serao bastante simples de tu os
solucinares !!!
o 1? e so seguinte:
Eu tenho tido uns problemazitos com os meus controladores usb que jah
resolvi, e portanto consegui recente-mente que o meu kernel detecta-se a
minha unidade de grava??o HP8200e.
O aparelho aparece nos scsi devices como devia!!
No entanto eu nao sei a que ficheiro do sistema ? que ele est? designado....
( sda1 sda2....... ) ou outro qq.
Gostava que medisses como e que isso se descorbre, uma vez que nap aparece
nada do fstab jah que quando instalei o red hat 7.2 de opri9gem ele naop me
r~econheceu as saidas usb, o que so aconteceu numa compila??o posteriror do
kernel.
o 2? problema e o seguinte!!!!!
Eu estou a pensar em comprar um computador novo. E o setup que tenho pensado
? o seguinte:
Mother Board D850GB AL 46800
Processador Intel P4 1,8 GHz 70800
Disco R?gido Seagate Cheeta 4Mb Cache 10.000 Rpm 32 Gigas 110400 (queria o
de 73 gigas e 16 mb cache mas 300 contos nao dah para mim)
Controlodor SCSI Adaptec SCSI Ultra 160 99000
Placa de V?deo Matrox G450 22800
Mem?ria Ram 1 GHz 119520 ( 2 rims de 512 isso explica o presso a gb so
trabalha com rims)
Drive de Diskettes Drive 3.5 3000
Cd-Rom 52x Creative 52x 8640
Caixa do PC P4 Tower + Cooling 44160 ( o cooling adicional sao duas
ventoinhas de 11 cm de diametro ligadas directamente a 22~0volts)
Total 525120
( pre?os sem iva e em escudos )
E eu ecrevi um setup semelhante numa msg qu emandei a outros gajo e todo
eles me disseram para investir em athlon que o que se poupa n ram e no
processador e na ~board dah para investir em outras cenas!!!!!!
A minha per gunta e a seguinte:
Se eu investir em Athlon 1.8 GHz por exemplo, que board e que escolho??? Nao
gosto das Asus tec ( ate podem ser boas mas nao gosto delas ).
Para o pentium era simples INTEL e pronto mas e para AMD?? Qual e a boarde
de QUALIDADE e que tenha uma assistencia convincente???
Jah agora mais uma coisa, nas diuversas respostas que me deram acerca deste
tema disseram -me o seguinte:
"
Ram => 1000 mb ram 2x 512 rims
That is an unfortunate amount of RAM. Rather than forcing everyone
to run their OS the same way, Linux lets people with smaller amounts
of memory avoid the overhead needed to handle large amounts of memory.
There are 3 configs:
2 MB to 896 MB (fastest)
up to 2 or 4 GB (upper limit depends on your motherboard)
up to nearly 64 GB (slowest)
As you can see, 1 GB is just barely into the second config.
You might consider instead 512 MB, 768 MB, 1.5 GB, or 2 GB."
E SOBRE O CHIPSET O SEGUINTE:"Don't get a VIA motherboard. Linux 2.4.17 has
workarounds for
the two most serious problems, but still... VIA tried very hard
to hide the problems, even blaming Creative Labs for a while
Legacy Fishtank <[email protected]> wrote:
>I don't see the masses, or, well, anybody on lkml, clamoring for this.
I'm one of the masses who are *not* clamoring for this. Neither kbuild 2.5 nor
CML2 will provide any benefits for me; I'm going to be enduring them (because I
have no choice), rather than welcoming them.
Wayne
[CC trimmed]
On Sat, 29 Dec 2001, Keith Owens wrote:
> [...]
> Auto detection of changed commands/flags
>
> That was a decent fix for part of the problem, but it did not address
> tracking user commands nor host compiles. It did not allow for
> separate source and object trees, for read only source trees, nor did
> it handle the more esoteric cases like modules being built from
> multiple directories.
Some people asked for what my patch looked like, so I resurrected it. I
moved it to 2.5.2-pre3. As it caused lots of rejects (maintaining kbuild
is a non-trivial task, isn't it, Keith?), I only fixed the problems for my
.config. So the attached patch will break with most .configs. However,
people who want to take a look can take my .config and play with that -
it's strictly proof-of-concept only.
(The breakage is easily fixable, it's just quite a bit of mostly trivial
work).
And yes, it doesn't fix the separate source / objects tree issue. But IMO
that's not a problem that needs to be fixed, it's an additional feature
which I didn't even try to attack (it may be possible to get there with
VPATH, though).
To try it, patch your kernel,
mv ../config-2.5 .config
make oldconfig
make # builds bzImage and modules
A subsequent make will only rebuild what's needed:
[kai@vaio linux-2.5.2-pre3.kbuild]$ time make
make -f Makefile.build boot
make[1]: Entering directory
`/home/kai/kernel/v2.5/linux-2.5.2-pre3.kbuild'
Generating include/linux/compile.h ...
Preprocessing arch/i386/boot/bsetup.s ...
Assembling (AS) arch/i386/boot/bsetup.o ...
Linking arch/i386/boot/bsetup ...
Compiling init/version.o ...
Linking vmlinux ...
Generating System.map ...
Building arch/i386/boot/compressed/piggy.o
Linking arch/i386/boot/compressed/bvmlinux
Copying to arch/i386/boot/compressed/bvmlinux.out
Building arch/i386/boot/bzImage
Root device is (3, 2)
Boot sector 512 bytes.
Setup is 4764 bytes.
System is 715 kB
make[1]: Leaving directory `/home/kai/kernel/v2.5/linux-2.5.2-pre3.kbuild'
real 0m10.230s
user 0m8.510s
sys 0m1.050s
For each make, compile.h is updated, thus causing init/version.o to be
recompiled and vmlinux to be relinked. - I kept the behavior of the
current kbuild. Not regenerating compile.h will give:
[kai@vaio linux-2.5.2-pre3.kbuild]$ time make
make -f Makefile.build boot
make[1]: Entering directory
`/home/kai/kernel/v2.5/linux-2.5.2-pre3.kbuild'
make[1]: Nothing to be done for `boot'.
make[1]: Leaving directory `/home/kai/kernel/v2.5/linux-2.5.2-pre3.kbuild'
real 0m7.155s
user 0m6.790s
sys 0m0.290s
As an example, change one file:
[kai@vaio linux-2.5.2-pre3.kbuild]$ touch drivers/isdn/hisax/callc.c
[kai@vaio linux-2.5.2-pre3.kbuild]$ time make
make -f Makefile.build boot
make[1]: Entering directory
`/home/kai/kernel/v2.5/linux-2.5.2-pre3.kbuild'
Compiling drivers/isdn/hisax/callc.o ...
Linking module drivers/isdn/hisax/hisax.o ...
make[1]: Leaving directory `/home/kai/kernel/v2.5/linux-2.5.2-pre3.kbuild'
real 0m9.433s
user 0m8.780s
sys 0m0.520s
$ diffstat pp-kbuild-2.5.2-pre3
00_version | 5
Documentation/DocBook/Makefile | 3
Makefile | 507 +++----------------------
Makefile.build | 460 ++++++++++++++++++++++
Makefile.config | 32 +
Makefile.end | 37 +
Makefile.vars | 130 ++++++
Rules.make | 326 ----------------
arch/i386/Makefile | 70 ---
[...]
scripts/Makefile | 23 -
scripts/fix_dep.c | 406 ++++++++++++++++++++
scripts/mkdep.c | 628 -------------------------------
169 files changed, 1849 insertions(+), 3107 deletions(-)
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.
Personally I'd like to see each C file have a header like
this too, describing in a few lines what the functions in
this file are supposed to do.
This should make it easier for people to figure out not just
what each C file is about, but also if they should spend their
time wading through this particular C file when in search of
some piece of code.
regards,
Rik
--
Shortwave goes a long way: irc.starchat.net #swl
http://www.surriel.com/ http://distro.conectiva.com/
On Sat, 29 Dec 2001, Keith Owens wrote:
> ps. I don't want mail discussing individual bug fixes to mkdep. Code
> that does not fix _all_ 9 bugs listed in makefile-2.5_make_dep.html
> is pointless.
I guess you presented a good point to not ignore bug number
10 (the speed one) either. ;)
Rik
--
Shortwave goes a long way: irc.starchat.net #swl
http://www.surriel.com/ http://distro.conectiva.com/
On Sat, Dec 29, 2001 at 08:24:37PM +1100, Anton Blanchard wrote:
> How large is your core db stuff? The thing I like about tdb is that it
> is very simple, only recently growing over 1024 lines.
1404 4736 32921 mdbm.c
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
Keith Owens wrote:
> Run make dep after -
>
> A change to .config.
Ok
> Any source change, it might have changed the #include list.
> Any source or command line change that affects generated files.
Not really, I only need to run "make dep" if I change a #include or
mess with generated files somehow. When I'm hacking on a driver, I
think I'm supposed to be clever enough to realise when it's time to
run "make dep".
When I apply a patch from somebody else, I usually don't know exactly
what has changed, so to be on the safe side I should always run "make
oldconfig && make dep" after applying a patch.
If I move the kernel tree so that the absolute paths won't match any
more, I also run "make dep".
> How do you automate that? You end up saying that you always run make
> dep.
I don't want to automate that. In my opinion trying to automatically
figure out when to run make dep is overkill (except to run make dep a
first time when it hasn't been run before).
Anyway, from what you have said it seems as if the slowdowns are due
to two things, checking dependencies every time and doing the
translation of absolute to relative paths. I'm not arguing against
kbuild-2.5, what I want to say is that I think that not all of the
nine bugs you mention are showstoppers. If you can get kbuild-2.5
into the kernel without the absolute->relative translation, why not do
it?
I just noted the option:
make NO_MAKEFILE_GEN=anything
which allows me to test things rather quickly (does this avoid the
absolute->relative conversion?) so it seems as if you've fixed this
already. :-)
One thing I'd like to change though:
Error: the previous kbuild used NO_MAKEFILE_GEN, install is not safe
You must do a clean kbuild without NO_MAKEFILE_GEN before doing
install
I don't care that it is unsafe, if I know what I'm doing I don't want
the computer to say "Sorry Dave, I can't let you do that". My current
way of working with embedded systems is to install etherboot on the
machine and the suck the kernel over tftp and mount the root file
system using NFS. The way I work is usually:
change a source file (e.g. drivers/char/scx200_watchdog.c)
make SUBDIRS=drivers/char modules
make INSTALL_MOD_PATH=/export/nfs/00601D1D1D52 modules_install
reboot the target system and test the change
Of course I could just copy the module by hand, but when there is a
whole build system that does things, it would be nice to be able to
use it.
/Christer
--
"Just how much can I get away with and still go to heaven?"
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 similar drivers (ie "3com network devices",
whatever).
Linus
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 silly.
Make the dependency file itself depend on all the files it describes, and
add a makefile rule to re-generate it. Poof, problem gone.
> Dependencies _do_ change when your .config changes,
Only if you do them wrong. Look at mkdep.c - it statically determines the
complete list of header files that _can_ be included, and does not care at
all about what config options there are.
> that are included varies. gcc -MD gets this exactly right, gcc knows
> which files it read.
Bzzt, it knows the subset of files to read, nothing more.
Linus
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?
> unless PCI suppress dependent USB HOTPLUG_PCI
And there's hope this will die soon too (USB) ...
> unless (X86 or ALPHA or MIPS32 or PPC) suppress usb
or SPARC or SPARC64 (iirc) or ARM (once !pci usb is allowed)...
> unless (X86 and PCI and EXPERIMENTAL) or PPC or ARM or SPARC suppress dependent IEEE1394
Wouldn't the experimental be global? And maybe the PCI too?
> It seems to me *extremely* unlikely that a typical patch from a PPC maintainer
> would mess with any of these! They're rules that are likely to be written
> once at the time a new port is added to the tree and seldom or ever changed
> afterwards.
But they will be modified for new arch X, or when constraint X (like
PCI) is removed.
--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
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.
> > unless (X86 and PCI and EXPERIMENTAL) or PPC or ARM or SPARC suppress dependent IEEE1394
>
> Wouldn't the experimental be global? And maybe the PCI too?
I don't understand what change you are suggesting.
> > It seems to me *extremely* unlikely that a typical patch from a PPC
> > maintainer would mess with any of these! They're rules that are likely to
> > be written once at the time a new port is added to the tree and seldom or
> > ever changed afterwards.
>
> But they will be modified for new arch X, or when constraint X (like
> PCI) is removed.
Yes.
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
"Experience should teach us to be most on our guard to protect liberty when the
government's purposes are beneficient...The greatest dangers to liberty lurk in
insidious encroachment by men of zeal, well meaning but without understanding."
-- Supreme Court Justice Louis Brandeis
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.
It's not. In fact, I don't really see that implication either. There's
lots of drivers hidden under a CONFIG_PCI check, but nothing under an
ISA check. From ~line 104 to ~136 I suspect are all non-PCI and non-ISA
chipsets.
> > > unless (X86 and PCI and EXPERIMENTAL) or PPC or ARM or SPARC suppress dependent IEEE1394
> >
> > Wouldn't the experimental be global? And maybe the PCI too?
>
> I don't understand what change you are suggesting.
unless EXPERIMENTAL and (((X86 or PPC or SPARC) and PCI) or ARM)
Since the experimental tag I believe would be a global thing, and I'm
thinking that ARM probably implies !PCI (since it does so often, but I
don't know for sure..).
> > > It seems to me *extremely* unlikely that a typical patch from a PPC
> > > maintainer would mess with any of these! They're rules that are likely to
> > > be written once at the time a new port is added to the tree and seldom or
> > > ever changed afterwards.
> >
> > But they will be modified for new arch X, or when constraint X (like
> > PCI) is removed.
>
> Yes.
Not typical than, but it could/will happen, from arch maintainer Y.
--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
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
CONFIG_ARCH_ACORN=y
Yet, we have in drivers/ide:
if [ "$CONFIG_ARCH_ACORN" = "y" ]; then
dep_bool ' ICS IDE interface support' CONFIG_BLK_DEV_IDE_ICSIDE $CONFIG_ARCH_ACORN
dep_bool ' ICS DMA support' CONFIG_BLK_DEV_IDEDMA_ICS $CONFIG_BLK_DEV_IDE_ICSIDE
dep_bool ' Use ICS DMA by default' CONFIG_IDEDMA_ICS_AUTO $CONFIG_BLK_DEV_IDEDMA_ICS
define_bool CONFIG_BLK_DEV_IDEDMA $CONFIG_BLK_DEV_IDEDMA_ICS
dep_bool ' RapIDE interface support' CONFIG_BLK_DEV_IDE_RAPIDE $CONFIG_ARCH_ACORN
fi
So I guess I've found a bug.
--
Russell King ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
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.
>
> RiscPC:
> CONFIG_PCI=n
> CONFIG_ISA=n
> CONFIG_ARCH_ACORN=y
>
> Yet, we have in drivers/ide:
> if [ "$CONFIG_ARCH_ACORN" = "y" ]; then
> dep_bool ' ICS IDE interface support' CONFIG_BLK_DEV_IDE_ICSIDE $CONFIG_ARCH_ACORN
> dep_bool ' ICS DMA support' CONFIG_BLK_DEV_IDEDMA_ICS $CONFIG_BLK_DEV_IDE_ICSIDE
> dep_bool ' Use ICS DMA by default' CONFIG_IDEDMA_ICS_AUTO $CONFIG_BLK_DEV_IDEDMA_ICS
> define_bool CONFIG_BLK_DEV_IDEDMA $CONFIG_BLK_DEV_IDEDMA_ICS
> dep_bool ' RapIDE interface support' CONFIG_BLK_DEV_IDE_RAPIDE $CONFIG_ARCH_ACORN
> fi
>
> So I guess I've found a bug.
I have removed the constraint in question.
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
Let us hope our weapons are never needed --but do not forget what
the common people knew when they demanded the Bill of Rights: An
armed citizenry is the first defense, the best defense, and the
final defense against tyranny.
If guns are outlawed, only the government will have guns. Only
the police, the secret police, the military, the hired servants of
our rulers. Only the government -- and a few outlaws. I intend to
be among the outlaws.
-- Edward Abbey, "Abbey's Road", 1979
Legacy Fishtank wrote:
> Kernel building is not for newbies.
Crap. Back in 1995, I had to compile a kernel to get Linux installed,
because the packaged kernel did not include support for ATAPI CD-ROM
drives. I had no Unix experience whatsoever, basically what you call a
newbie.
And, no, the situation has not changed. There are
- people/cooperations without Linux kernel compilation experience, who
might need a feature that's only available in a development kernel,
- *newbies*, that are generally interested in learning Linux in all its
ways.
Your attitude strikes me as unnessicarily elitist.
Cheers,
Viktor
--
Viktor Rosenfeld
WWW: http://www.informatik.hu-berlin.de/~rosenfel/
On Sun, 30 Dec 2001, Viktor Rosenfeld wrote:
> > Kernel building is not for newbies.
> Crap. Back in 1995, I had to compile a kernel to get Linux installed,
> because the packaged kernel did not include support for ATAPI CD-ROM
> drives. I had no Unix experience whatsoever, basically what you call a
> newbie.
Things have changed dramatically since 1995.
In particular, distros got a lot friendlier to install, and customise.
If theres a valid reason for Aunt Tillie to rebuild her kernel, it means
her distro of choice is doing something wrong.
> - people/cooperations without Linux kernel compilation experience, who
> might need a feature that's only available in a development kernel,
> - *newbies*, that are generally interested in learning Linux in all its
> ways.
> Your attitude strikes me as unnessicarily elitist.
Dumbing down the learning curve doesn't necessary make things easier
for people to learn. Reluctance to read documentation for eg is something
that will plague us no matter how simple we make it to build kernels.
Dave.
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs
On Sat, Dec 29, 2001 at 12:44:06AM +0100, Kai Germaschewski wrote:
> But yes, it seems possible to replace the -MD dependency file, which
> depends on a specific config, with a generic dependency file, which knows
> about our #ifdef CONFIG_XXX and translates them to the corresponding
> ifeq(CONFIG_,) Makefile syntax. It'd make an interesting project, but it
> effectively means re-implementing a C preprocessor.
Michael already wrote such a program. It's part of the dancing
makefiles patch, which btw is a kernel build system that is not only
correct but also faster than the old one..
It's scripts/mk/fix_dep.c in a kernel tree with the following patch
applied:
ftp://ftp.kernel.org/pub/linux/kernel/projects/kbuild/dancing-makefiles-2.4.0-test10.bz2
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 devices.
I've never seen one, but we've got drivers for them. See PARIDE and
paride_devices.
Rob
> > > 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 conceivable bus or interface.
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 have useful results.
Is your native language something different th?n english or Al's?
Localization for technical messages sucks. badly.
Just take a look at a european computer magazine, you will find lots of
english words in the text because there is no german/frensh/whatever
one. Trying to use different grammar doesn't help the understanding.
Christoph
--
Of course it doesn't work. We've performed a software upgrade.
Dave Jones wrote:
> Things have changed dramatically since 1995.
> In particular, distros got a lot friendlier to install, and customise.
> If theres a valid reason for Aunt Tillie to rebuild her kernel, it means
> her distro of choice is doing something wrong.
Yes, Aunt Tillie should not have to build a new kernel. But 13-year-old
Joe Geek might want to try that out, as well as your next door neighbor,
who just might be an IT guy, trying to switch his department to Linux.
> Dumbing down the learning curve doesn't necessary make things easier
> for people to learn. Reluctance to read documentation for eg is something
> that will plague us no matter how simple we make it to build kernels.
I'm not talking about dumbing down the learning curve. This is about
tools that do the job they're supposed to do in a correct way, without
having to rely on some inside voodoo magic, that is poorly documented,
if at all.
Cheers,
Viktor
--
Viktor Rosenfeld
WWW: http://www.informatik.hu-berlin.de/~rosenfel/
[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 +0000, 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 shouldn't be done at the same time as introducing CML2.
Yes, but what I was getting at was that these constraints will change
(either because they were incorrect or no longer aplicable).
Either way, why not fix bugs now? (since there are non-PCI/ISA ide,
which is why I kept that example to start with).
--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
On Sun, Dec 30, 2001 at 05:14:22PM +0000, 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 shouldn't be done at the same time as introducing CML2.
Existing rules allow non-PCI/ISA IDE. Its a bug, not a change of
behaviour.
--
Russell King ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
Christoph Hellwig wrote:
> Localization for technical messages sucks. badly.
> Just take a look at a european computer magazine, you will find lots of
> english words in the text because there is no german/frensh/whatever
> one. Trying to use different grammar doesn't help the understanding.
Or take a look at a BSD or Linux Web page in one of the oriental
languages... even it contains English quite often.
Jeff
--
Jeff Garzik | Only so many songs can be sung
Building 1024 | with two lips, two lungs, and one tongue.
MandrakeSoft | - nomeansno
[email protected] (Alan Cox) wrote on 28.12.01 in <[email protected]>:
> > 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 to deal with the resulting mess for real?
>
> The biggest advocates I see are from the Middle-East and Japan. We already
> have people providing translations for Configure.help in several languages.
Once upon a time, I installed the German version of the man pages. Shortly
after that, I switched to doing "LANG= man ..." because of exactly the
problem Al mentions.
But just recently I have been considering going back to the German man
pages, because the quality has become *MUCH* better. In fact, it's now
obvious they are fairly close translations of the English ones.
In short, i18n for Linux has been improving drastically at least in some
areas. Of course that won't be the same for all target languages; German
is probably one of the best-supported ones because Linux usage in Germany
is so heavy.
As for Configure.help specifically: it should be fairly easy to do a
script which notices when the original of a translation has changed, and
possibly either replaces it with the English version, or else does some
other more or less intelligent thing about it.
MfG Kai
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* demand for localization and that meeting
> > it can have useful results.
>
> Is your native language something different th?n english or Al's?
>
> Localization for technical messages sucks. badly.
> Just take a look at a european computer magazine, you will find lots of
> english words in the text because there is no german/frensh/whatever
> one. Trying to use different grammar doesn't help the understanding.
For some people it helps when the text is in e.g. German although the
technical words are still English.
The most important point I see is: If the tanslation works similar to
gettext, IOW there's a seperate directory that contains the complete
translations I can't see problem for the "normal" kernel hacker: You don't
have to care about the translations but if someone wants to provide a
translation to e.g. Esperanto he can always do so by adding a file with
the translated texts. People like you and me who prefer the English
version can always use it but other people who prefer the translated
messages can use them instead.
> Christoph
cu
Adrian
Jeff Garzik wrote:
> Christoph Hellwig wrote:
>
>>Localization for technical messages sucks. badly.
>>Just take a look at a european computer magazine, you will find lots of
>>english words in the text because there is no german/frensh/whatever
>>one. Trying to use different grammar doesn't help the understanding.
>>
>
> Or take a look at a BSD or Linux Web page in one of the oriental
> languages... even it contains English quite often.
>
Best example is IBM. It's only possible to install the DB2 client
in your native Language (may be German) on Windows. The manual's are
in English. So, for example a trigger is a Ausl?ser - very strange.
May be they should translate the SQL Language to. Would be a little
bit easier and I can start with computing from scratch again.
Another nice thing is Excel. You use German for the table and English
for VB programing. For example: table: zeichen() == VB char().
On the other hand, the only population who dubbed/translate every
movie/thing into German, are the German's. Most others (for example Scandinavia,
Netherland) use the original Language (mostly English) with subtitles.
Hartmut
At Fri, 28 Dec 2001 23:20:01 +0000 (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 feeling, but could you please listen to those
> > of us who have to deal with the resulting mess for real?
>
> The biggest advocates I see are from the Middle-East and Japan. We already
> have people providing translations for Configure.help in several languages.
Yes. We JF Project (Japan) is still keeping translating Configure.help
into Japanese for the stable kernel version 2.0, 2.2, and 2.4.
We have some interest in distributing our translated-Configure.help,
but, such distribution needs so-high-precious technical translation.
I think to leave quality control of Configure.help from developer
is not good, we have to be so careful, and it's a big problem.
In addition, I think we need a framework for keeping up to date with
the latest Configure.help against translated Configure.help.
Consistency between original Configure.help and translated-Configure.help
must be kept. IMHO, for example, if CONFIG_FOO is changed between 2.4.16
and 2.4.17, then (translated-)CONFIG_FOO must show in original English,
even if we have only 2.4.16-translated-CONFIG_FOO, and so on.
-- gotom
At 30 Dec 2001 13:42:00 +0200,
Kai Henningsen wrote:
> But just recently I have been considering going back to the German man
> pages, because the quality has become *MUCH* better. In fact, it's now
> obvious they are fairly close translations of the English ones.
Well, I don't know the quality of German's, but I know German's have
much of localized message :) However, imagine other languages. The
quality control of localized translation can know only people who are
ready for that language. I think it's the problem.
> As for Configure.help specifically: it should be fairly easy to do a
> script which notices when the original of a translation has changed, and
> possibly either replaces it with the English version, or else does some
> other more or less intelligent thing about it.
Well, such a mechanism is also needed whenever if we have official
translation system (like DDTS - Debian Description Translation System).
-- gotom
Em Mon, Dec 31, 2001 at 07:51:23PM -0300, Horst von Brand escreveu:
> Alan Cox <[email protected]> said:
> > Something like:
> >
> > find $TOPDIR -name "*.cf" -exec cat {} \; > Configure.help
>
> Make that:
>
> cat `find $TOPDIR -name "*.cf"` > Configure.help #;-)
whatever is faster, do you have trustable benchmark numbers? ;)
Yes, its a joke, have a nice 2002 all!
- Arnaldo
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 +56 32 672616
"Eric S. Raymond" <[email protected]> said:
[...]
> Which is why there are organized translation groups that do periodic
> translation updates for software that has registered with them. This
> doesn't eliminate the problem, but it can keep it within manageable bounds
> that make having localizations better than not. I deal with this regularly
> with respect to fetchmail.
Translations do suck: In Spanish, there are several "dialects" of computer
terms in common use. Get a book written in one of those, and try to make
sense on texts using another convention. Or just try to read the original
English documentation...
To do a good translation you need (a) good understanding of the source
language (enough to be able to work around bugs in the original rendering),
(b) extensive knowledge of the target language, (c) knowledge of the task
at hand. Getting all three together is hard.
Besides, stuff like comments and help messages does suffer bitrot very much
as it doesn't (much) affect functioning, translations are much worse as
they have even less exposure (== even less selective pressure to stay right).
[...]
> No, not always. I read French, Italian, and Spanish; I can puzzle out
> technical prose in a couple of other languages. I can read
> fetchmail's .po files and *see* that they don't suck.
You _know_ what the English text says. To be able to make sense of a text
when you have a rather clear idea what it says is a lot easier than trying
to puzzle it out when you have no clue.
Not to say that the files in fetchmail aren OK (I looked at them myself
(German, Spanish) a while back and found little to patch).
--
Horst von Brand [email protected]
Casilla 9G, Vin~a del Mar, Chile +56 32 672616
[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 ... depends on the nature of your
bottlenecks, I guess, and cold vs. hot cache. Or you could have it
both ways:
find $TOPDIR -name \*.cf | xargs -n10 cat > Configure.help
...where 10 is tuned by benchmarking. (:
> Yes, its a joke, have a nice 2002 all!
Yeah, same from me..
Peter
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 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 of the core code will use a shared database with
> concurrent update so post processing is limited to looking up just the
> required files, instead of reading the complete list every time.
Why not use '$(GCC) -c -Wp,-MD,foo.d foo.c' to generate the dependencies
as a side effect of the regular compile step? This enables you to skip
the initial dependency preprocessing step entirely, and could lead to a
speedup over even the current fastdep system. You still have to massage
the dependencies but you can do it based on the side-effect dependency
output of the _previous_ build, to whatever degree that output exists.
This strategy allows for lazy dependency generation in those cases in
which the dependencies need not be known--for example, if floppy.o
doesn't exist, you know it needs to be built no matter which header
files floppy.c may include. This breaks down in some cases (as when a
.c file depends on a generated .h file) but those breakdown cases can
be explicitly identified, and a full dependency tree be generated for
them in an eager, rather than a lazy, fashion.
It seems like it's worth it if it leads to a near 100% speedup over the
current kbuild 2.5. The "build whole clean tree" case is a common one
even among kernel developers, e.g. for compile-testing patches before
resending them.
miket
Christoph Hellwig <[email protected]> said:
> 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 have useful results.
> Is your native language something different th?n english or Al's?
>
> Localization for technical messages sucks. badly.
> Just take a look at a european computer magazine, you will find lots of
> english words in the text because there is no german/frensh/whatever
> one. Trying to use different grammar doesn't help the understanding.
It is even worse when they try to "translate" the terms. In Spanish, the
official language calls a computer "ordenador" (sorting device), and a file
"fichero" (filing cabinet). It doesn't help in the least at understanding
the _English_ documentation/source/... Add to it that here in South America
they usually take over the English terms, using "computador" (computing
device) and "archivo" (file). So it can even make it hard to understand the
technical literature in your own language... My standard advise is to learn
English, if nothing else for uniformity's sake. You'll need it anyway
before long in anything related to computing. And it is quite useful in
other areas...
--
Horst von Brand [email protected]
Casilla 9G, Vin~a del Mar, Chile +56 32 672616
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 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 of the core code will use a shared database with
>> concurrent update so post processing is limited to looking up just the
>> required files, instead of reading the complete list every time.
>
>Why not use '$(GCC) -c -Wp,-MD,foo.d foo.c' to generate the dependencies
>as a side effect of the regular compile step? This enables you to skip
>the initial dependency preprocessing step entirely, and could lead to a
>speedup over even the current fastdep system. You still have to massage
>the dependencies but you can do it based on the side-effect dependency
>output of the _previous_ build, to whatever degree that output exists.
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 where all the files are before it can convert the absolute
dependencies produced by gcc. Reading and indexing that file for every
compile is _slow_.
Larry McVoy has sent me the source code to an mmapped database (from
bitkeeper). Using a shared mmapped database should speed the process
up considerably.
[Mike Touloumtzis]
> Why not use '$(GCC) -c -Wp,-MD,foo.d foo.c' to generate the
> dependencies as a side effect of the regular compile step?
As Keith said, kbuild 2.5 *does* use 'gcc -MD' - although the *current*
system does not.
Linus has said that he doesn't like -MD, and he has a point: it only
extracts dependencies for your *current* compile, which means they have
to be rebuilt if you change CONFIG options. However, those CONFIG
options would cause rebuilding of the file *anyway*, and -MD is almost
free since the preprocessor already has to read the files in question,
so I'm not convinced that it's a big deal.
> The "build whole clean tree" case is a common one even among kernel
> developers, e.g. for compile-testing patches before resending them.
One of the main points of kbuild 2.5 is that, unlike the current
system, it tracks dependencies perfectly. Thus you should almost never
have to run 'make clean' before test compiling something - unless you
need to see non-fatal compile warnings.
It may take some time to get used to the soon-to-be new reality of "ok,
so I just applied eight kernel patches from three different places but
I know I don't need to bother with 'make clean' because the dependency
system is just *that good*."
Peter
Hi!
> > > On Sat, Dec 29, 2001 at 03:44:10PM +1100, Keith Owens wrote:
> > > > What Mr. Fishtank seems to overlook is that kbuild 2.5 is far more
> > > > flexible and accurate than 2.4, including features that lots of people
> > > > want, like separate source and object trees.
> > >
> > > I don't see the masses, or, well, anybody on lkml, clamoring for this.
> >
> > Clamour.
>
> Clamour.
Clamour.
Being able to cp -a then build without full rebuild is good. Also make dep
takes *long* and and bad things happen when you think it was not needed ;-).
Pavel
--
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.
On Thu, 3 Jan 2002, Pavel Machek wrote:
> Being able to cp -a then build without full rebuild is good. Also make dep
> takes *long* and and bad things happen when you think it was not needed ;-).
And being able to NFS share 1 kernel tree, and be able to do parallel
builds on multiple boxes without having to wait until 1 is finished.
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs
On Thu, 3 Jan 2002, Dave Jones wrote:
> On Thu, 3 Jan 2002, Pavel Machek wrote:
>
> > Being able to cp -a then build without full rebuild is good. Also make dep
> > takes *long* and and bad things happen when you think it was not needed ;-).
>
> And being able to NFS share 1 kernel tree, and be able to do parallel
> builds on multiple boxes without having to wait until 1 is finished.
Sigh... As soon as we get to prototype change in
getattr()/setattr()/permission() - we get CoW fs. I.e. equivalent of
*BSD unionfs. I hope to get around to that stuff around 2.5.4 or so.
On Thu, 3 Jan 2002 15:35:19 -0500 (EST),
Alexander Viro <[email protected]> wrote:
>On Thu, 3 Jan 2002, Dave Jones wrote:
>> And being able to NFS share 1 kernel tree, and be able to do parallel
>> builds on multiple boxes without having to wait until 1 is finished.
>
> Sigh... As soon as we get to prototype change in
>getattr()/setattr()/permission() - we get CoW fs. I.e. equivalent of
>*BSD unionfs. I hope to get around to that stuff around 2.5.4 or so.
Unionfs and cow fs will be nice but kernel build will not use it.
Users can build a Linux kernel on other operating systems, including
Solaris, Irix, Cygwin etc. kbuild requires a Posix compliant fs and
GNU tools, but it must not use additional fs features that only exist
on Linux or only on specific versions of Linux.
On Fri, 4 Jan 2002, Keith Owens wrote:
> On Thu, 3 Jan 2002 15:35:19 -0500 (EST),
> Alexander Viro <[email protected]> wrote:
> >On Thu, 3 Jan 2002, Dave Jones wrote:
> >> And being able to NFS share 1 kernel tree, and be able to do parallel
> >> builds on multiple boxes without having to wait until 1 is finished.
> >
> > Sigh... As soon as we get to prototype change in
> >getattr()/setattr()/permission() - we get CoW fs. I.e. equivalent of
> >*BSD unionfs. I hope to get around to that stuff around 2.5.4 or so.
>
> Unionfs and cow fs will be nice but kernel build will not use it.
> Users can build a Linux kernel on other operating systems, including
> Solaris, Irix, Cygwin etc. kbuild requires a Posix compliant fs and
> GNU tools, but it must not use additional fs features that only exist
> on Linux or only on specific versions of Linux.
<shrug> kernel build doesn't have to use it - if I mount a writable layer
atop of the clean tree and build in the resulting tree, build system
doesn't need to have any idea of that fact. That's the point - you are
emulating the thing that is generally useful and belongs to different
layer - namely, the kernel.
On Thu, 3 Jan 2002 16:30:55 -0500 (EST),
Alexander Viro <[email protected]> wrote:
><shrug> kernel build doesn't have to use it - if I mount a writable layer
>atop of the clean tree and build in the resulting tree, build system
>doesn't need to have any idea of that fact.
I have one big problem with unionfs and make, it cannot handle this
scenario.
* Mount COW layer over clean tree.
* Edit a file, writing to the COW layer.
* Build the kernel.
* Decide that you don't want the change, delete the COW version,
exposing the original version of the file, timestamp goes backwards.
* Build the kernel.
* make sees source timestamp < object timestamp and does not rebuild,
the kernel source and object do not match.
Obviously this is a design flaw in make, using only timestamps has been
shown to be unreliable. As long as people use the standard make
program, they will have problems with union filesystems. The problem
is not restricted to unionfs, NFS timestamp skew also affects make, as
well as checking out code from source repositories when the timestamp
goes backwards.
>That's the point - you are
>emulating the thing that is generally useful and belongs to different
>layer - namely, the kernel.
I agree that unionfs is useful but it is not the panacea for kbuild
that you think it is. The kbuild wrapper around make takes care of the
timestamp problems as well as handling separate source and object
trees, IOW it does unionfs plus a lot more work.
If make did not rely on timestamps I would have been pushing for
unionfs a long time ago, but as long as we are stuck with make's
design, unionfs is not a fix. I thought about replacing make entirely
with another tool like Scons but decided that none of the other tools
on their own could cope with the peculiarities of the kernel build nor
were they stable enough yet.
On Fri, 4 Jan 2002, Keith Owens wrote:
> * Mount COW layer over clean tree.
> * Edit a file, writing to the COW layer.
> * Build the kernel.
> * Decide that you don't want the change, delete the COW version,
> exposing the original version of the file, timestamp goes backwards.
ITYM "creating a whiteout entry". unlink() on unionfs doesn't expose
the underlying object.
It looks so:
* each directory in covering layer has a flag (is_transparent)
* all children of non-transparent directory are non-transparent
* lookup in non-transparent directory is a usual lookup in covering
layer.
* lookup in transparent directory
lookup in covering layer
if found an object -> return it
else if found whiteout -> no entry
else
do lookup in covered
if not found -> no entry
else if found is a directory
create a directory in covering
mark it transparent
return new directory
else -> return what we found
* mkdir creates non-transparent directories
* unlink and rmdir leave whiteout entry
* attempt to modify file copies it into covering and modifies that copy.
That gives you real copy-on-write semantics - when you remove object it
stays removed; rm -rf foo && mkdir foo gives you an empty directory, etc.
rename() support is messy - especially when it comes to renaming directories
(if it was transparent you need to copy the entire subtree to covering layer).
Whiteouts are usually represented as directory entries with no inode and
type of entry being DT_WHT (14). Adding support of these beasts into
ext2 is ~ 10 lines of patch.
On Thu, 3 Jan 2002 17:11:37 -0500 (EST),
Alexander Viro <[email protected]> wrote:
>On Fri, 4 Jan 2002, Keith Owens wrote:
>
>> * Mount COW layer over clean tree.
>> * Edit a file, writing to the COW layer.
>> * Build the kernel.
>> * Decide that you don't want the change, delete the COW version,
>> exposing the original version of the file, timestamp goes backwards.
>
>ITYM "creating a whiteout entry". unlink() on unionfs doesn't expose
>the underlying object.
It does in kbuild 2.5. You have a pristine source tree, start a
development layer, edit files, build a kernel, decide your edit was
wrong, delete the updated version, expose the original and kbuild 2.5
still gets it right. IMHO that model better fits kernel development.
The whiteout model makes it more difficult to revert to the standard
kernel, you have to copy the original code to your writeable layer to
back out changes. To satisfy the broken make design, you cannot copy
with timestamp. When the base layer changes to a new release, the COW
version does not get upgraded, even though it is supposed to be
identical to the base layer.
Again, I am not disagreeing with unionfs, it has its uses. kbuild
using make and relying solely on timestamps to detect changes is not
one of them. Especially when kbuild has to run on other operating
systems.
On Fri, Jan 04, 2002 at 08:50:52AM +1100, Keith Owens wrote:
> On Thu, 3 Jan 2002 16:30:55 -0500 (EST),
> Alexander Viro <[email protected]> wrote:
> ><shrug> kernel build doesn't have to use it - if I mount a writable layer
> >atop of the clean tree and build in the resulting tree, build system
> >doesn't need to have any idea of that fact.
>
> I have one big problem with unionfs and make, it cannot handle this
> scenario.
>
> * Mount COW layer over clean tree.
> * Edit a file, writing to the COW layer.
> * Build the kernel.
> * Decide that you don't want the change, delete the COW version,
> exposing the original version of the file, timestamp goes backwards.
> * Build the kernel.
> * make sees source timestamp < object timestamp and does not rebuild,
> the kernel source and object do not match.
Isn't that a thinko in there? The build using the edited file would
happen in the same layer as that file or in another one on top. If it's
the same, the build would be deleted with the change.
If it's in another one on top you'd be removing a layer in the middle.
I don't know if that should be possible without user intervention
(unmount build and change layers, delete change layer, mount build layer
over source). There is something said about Unix and ropes, I remember.
Then again I don't know the unionfs idea in these details, so I may be
wrong.
Unionfs as I understand it would be great for editing/patching and
building. Build a kernel in the pristine sources, mount a COW layer
over it where you patch/edit, build there. In the ideal case the COW
layer would only build the changed file(s) and link vmlinux with all the
other objects from the pristine build. This wouldn't affect the
pristine build itself at all, no make problems there when you remove the
COW build&change layer.
--
Andreas Bombe <[email protected]> DSA key 0x04880A44
On Fri, 4 Jan 2002 02:49:38 +0100,
Andreas Bombe <[email protected]> wrote:
>Unionfs as I understand it would be great for editing/patching and
>building. Build a kernel in the pristine sources, mount a COW layer
>over it where you patch/edit, build there. In the ideal case the COW
>layer would only build the changed file(s) and link vmlinux with all the
>other objects from the pristine build. This wouldn't affect the
>pristine build itself at all, no make problems there when you remove the
>COW build&change layer.
You are talking about removing an entire layer, I am talking about
removing individual files when you decide the edit failed. Removing
the entire layer works, as long as all changes are always made to the
top layer. Removing individual files gets into timestamp problems.
On Fri, Jan 04, 2002 at 01:31:08PM +1100, Keith Owens wrote:
> On Fri, 4 Jan 2002 02:49:38 +0100,
> Andreas Bombe <[email protected]> wrote:
> >Unionfs as I understand it would be great for editing/patching and
> >building. Build a kernel in the pristine sources, mount a COW layer
> >over it where you patch/edit, build there. In the ideal case the COW
> >layer would only build the changed file(s) and link vmlinux with all the
> >other objects from the pristine build. This wouldn't affect the
> >pristine build itself at all, no make problems there when you remove the
> >COW build&change layer.
>
> You are talking about removing an entire layer, I am talking about
> removing individual files when you decide the edit failed. Removing
> the entire layer works, as long as all changes are always made to the
> top layer. Removing individual files gets into timestamp problems.
Duh, you are right. That can't be solved cleanly.
--
Andreas Bombe <[email protected]> DSA key 0x04880A44
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 where all the files are before it can convert the absolute
> dependencies produced by gcc. Reading and indexing that file for every
> compile is _slow_.
I didn't follow the thread from the very beginning nor did I study
your makefiles carefully, because I don't have much time for kernel
hacking these days, but maybe I won't miss the pond :)
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?
I use it in one of my projects, there is the relevant part of the
Makefile:
# Black magic with dependencies. It would be more correct to make "depend.new"
# a prerequisite for "depend", but "depend.new" often has the same timestamp
# as "depend" which would confuse make a lot and either force remaking anyway
# or (as in current versions of GNU make) erroneously skipping the remaking.
-include depend
depend: force
if [ -s depend.new ] ; then build/mergedeps depend depend.new ; >depend.new ; fi
force:
# Implicit rules
obj/%.o: %.c
DEPENDENCIES_OUTPUT="depend.new $@" $(CC) $(CFLAGS) -c -o $@ $<
The DEPENDENCIES_OUTPUT mode is much more convenient than gcc -Mx as it
avoids scattering the relevant information over many files. The mergedeps
script is a simple Perl script which takes care of merging the dependencies
gathered during the previous run of make to the depend file for the next
run. It can do a lot of fixups and translations, here is a trivial
example:
#!/usr/bin/perl
@ARGV == 2 or die "Usage: mergedeps <base> <update>";
foreach $a (@ARGV) {
open F, "$a" or next;
$t = "";
while (<F>) {
$t .= $_;
if (! /\\$/) {
($t =~ /^(.*):/) || die "Parse error at $t";
$rules{$1} = $t;
$t = "";
}
}
close F;
}
open(F,">" . $ARGV[0]) || die "Unable to write output file";
foreach $a (sort keys %rules) {
print F $rules{$a};
}
close F;
Have a nice fortnight
--
Martin `MJ' Mares <[email protected]> http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
Light-year? One-third less calories than a regular year.
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 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 another over NFS without being bitten by absolute dependencies. I
really need to do that conversion using the current values of the
kbuild variables, the variables might have changed on the next make.
My new design for module symbol versions requires that the version data
be stored immediately after the compile. That also requires processing
after each compile using the current environment.
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 another over NFS without being bitten by absolute dependencies. I
> really need to do that conversion using the current values of the
> kbuild variables, the variables might have changed on the next make.
Yes, I understand, but this could be done as well at the start of the
make run, couldn't it?
> My new design for module symbol versions requires that the version data
> be stored immediately after the compile. That also requires processing
> after each compile using the current environment.
This sounds worse ... damned modversions, I still think it was one of the
biggest mistakes in Linux history and an one which will be probably very
hard to get rid of. Anyway, why do you need to process it immediately?
Have a nice fortnight
--
Martin `MJ' Mares <[email protected]> http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
Minimalist definition of maximalism: `more!'.