public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: Mark Galeck <mark_galeck@pacbell.net>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: is it desirable to improve the build system?
Date: Mon, 1 Jul 2013 21:45:16 -0700	[thread overview]
Message-ID: <20130702044516.GA31484@kroah.com> (raw)
In-Reply-To: <1372723921.53875.YahooMailNeo@web182202.mail.bf1.yahoo.com>

On Mon, Jul 01, 2013 at 05:12:01PM -0700, Mark Galeck wrote:
> Dear Linux-Kernel Community,
> 
> I am a consultant specializing in builds, and I recently worked for a
> large client company, a world-wide leader in its field, where I
> overhauled their build system: sped it up by more of an order of
> magnitude, and improved maintainability, for example making
> comment-to-code ratio approach 1:1. 
> 
> A part of their build is a modified Linux kernel. I rebuilt it
> countless times in various configurations, but made only a few further
> changes, because those improvements would have a small effect on the
> whole system, and because they want to stay close to your current
> release for ease of porting.
> 
> From that limited experience, it nevertheless seemed to me, that the
> Linux kernel build, while correct, is somewhat slow, and the sources
> could be more readable.

How is it "slow"?  And it has to be correct, fast and non-correct
doesn't work well, does it :)

What "sources" are you referring to as being not readable?

> Does the Linux-Kernel Community perceive that is the case?
> 
> If so, do you think it is possible to improve?
> 
> If so, would such an attempt be welcome, including and especially by,
> the current maintainer(s) of the build?  Of course it would have to be
> completely backwards-compatible, including to the text output
> interface and requirements for modules makefiles.

Patches are always gladly accepted, if they work well, please feel free
to submit them.

> I do apologize if my impressions are simply the result of
> unfamilliarity and naivete, and that I don't understand the deep
> reasons why "it has to be this way", and that I am unaware that such
> attempts were already made by some very skilled people.  

What do you not understand that you think could be changed?

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.

thanks,

greg k-h

  reply	other threads:[~2013-07-02  4:44 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-02  0:12 is it desirable to improve the build system? Mark Galeck
2013-07-02  4:45 ` Greg KH [this message]
2013-07-02  8:46   ` Mark Galeck
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=20130702044516.GA31484@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark_galeck@pacbell.net \
    /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