From: Mark Galeck <mark_galeck@pacbell.net>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: is it desirable to improve the build system?
Date: Tue, 2 Jul 2013 01:46:45 -0700 (PDT) [thread overview]
Message-ID: <1372754805.73620.YahooMailNeo@web182206.mail.bf1.yahoo.com> (raw)
In-Reply-To: <20130702044516.GA31484@kroah.com>
>> Linux kernel build, while correct, is somewhat slow, and the sources
>> could be more readable.
Greg wrote:
>How is it "slow"?
Well, the proportion of time spent by the CPU cores on activities other than compiling seemed high.
>What "sources" are you referring to as being not readable?
Not "not readable at all", just "could be made more readable" - the main Makefile and other main Make files; it seemed that one reason, IMHO, was not enough comments.
>What do you not understand that you think could be changed?
I did not make careful notes in that area (details would come back to me if I look at this carefully), but right now I remember two things.
As every child in kindergarten knows, recursive make is bad (except when it is good, which you learn in primary school). One reason is that all that re-parsing costs time. Linux kernel build is very heavy recursive.
Frequent use of FORCE phony prerequisites to circumvent the normal GNU Make recipe avoidance mechanism, and then using a custom recipe mechanism to decide what to execute, seems to go against the philosophy of the tool being used (GNU Make) and as such seems, IMHO, to also waste time.
Of course if one were to attempt a change, the first thing would be to do look carefully at the amount of time spent on such activities, rather than using words such as "seems".
What I don't understand of course is the reasons behind these choices have been made.
>Have you looked at the history of the build code to help understand why
things were changed to be they way they are? git should help you out
here.
No. IMHO, looking at source, and especially past history thereof, to understand it, is a very inefficient use of one's time, only to be undertaken if all else fails. Much better is looking at comments and documentation, if available, and also, asking well-informed persons such as yourself.
Mark
next prev parent reply other threads:[~2013-07-02 8:54 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-02 0:12 Mark Galeck
2013-07-02 4:45 ` Greg KH
2013-07-02 8:46 ` Mark Galeck [this message]
2013-07-02 14:51 ` Greg KH
2013-07-11 11:38 ` Pavel Machek
2013-07-11 20:40 ` Bjorn Helgaas
2013-07-11 21:22 ` Mark Galeck
2013-07-12 8:32 ` Richard Cochran
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1372754805.73620.YahooMailNeo@web182206.mail.bf1.yahoo.com \
--to=mark_galeck@pacbell.net \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®