From: ebiederm@xmission.com (Eric W. Biederman)
To: David Miller <davem@davemloft.net>
Cc: cl@linux.com, linux-kernel@vger.kernel.org
Subject: Re: [rfc] built-in native compiler for Linux?
Date: Sat, 25 Apr 2009 00:06:22 -0700 [thread overview]
Message-ID: <m163gtxle9.fsf@fess.ebiederm.org> (raw)
In-Reply-To: <20090424.222952.83381016.davem@davemloft.net> (David Miller's message of "Fri\, 24 Apr 2009 22\:29\:52 -0700 \(PDT\)")
David Miller <davem@davemloft.net> writes:
> From: Christoph Lameter <cl@linux.com>
> Date: Fri, 24 Apr 2009 14:34:49 -0400 (EDT)
>
>> On Wed, 22 Apr 2009, Ingo Molnar wrote:
>>
>>> What i think makes sense is to build a _new_ precompiler / compiler
>>> / assembler / linker combo for Linux, from scratch, hosted in the
>>> kernel proper.
>>>
>>> A good technical basis for that would be Sparse, and it could start
>>> by acting as a drop-in replacement for CPP and it could feed its
>>> output to GCC with little changes. Sparse is small, has a very tidy
>>> code base and is already useful today as an extended static source
>>> code checker.
>>
>> A new preprocessor would be great. If we can make sparse do what CPP does
>> now then lets go for it.
>
> It's just too bad that we'll lose the performance gained from the
> fact that GCC's CPP is linked into the C compiler binary and thus
> doesn't have to transfer it's result over a pipe or anything like
> that.
>
> I really think this whole idea isn't a very smart one. I would
> rather have whoever would be working on a sparse backend instead
> be working on kernel improvements.
>
> I also think people underestimate how much work this would be.
>From what little I have seen of this conversation I would have
to agree. I have written my own C compiler in roughly the manner
proposed in the original email and I would be happy to discuss how
much work it really is if someone is interested.
If this was about teaching sparse to run lockdep at compile time, or
generally about making the kernel compilation much faster and able to
catch many more bugs there might be a point where the effort is worth
the investment.
Eric
next prev parent reply other threads:[~2009-04-25 7:06 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-22 8:58 [rfc] built-in native compiler for Linux? Ingo Molnar
2009-04-23 20:22 ` Anton Ertl
[not found] ` <alpine.DEB.1.10.0904241429450.19686@qirst.com>
2009-04-25 5:29 ` David Miller
2009-04-25 7:06 ` Eric W. Biederman [this message]
2009-04-27 13:52 ` Christoph Lameter
2009-04-27 17:34 ` Al Viro
2009-04-27 18:41 ` Eric W. Biederman
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=m163gtxle9.fsf@fess.ebiederm.org \
--to=ebiederm@xmission.com \
--cc=cl@linux.com \
--cc=davem@davemloft.net \
--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