From: Carl-Daniel Hailfinger <c-d.hailfinger.kernel.2003@gmx.net>
To: Linus Torvalds <torvalds@transmeta.com>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
kernel-janitor-discuss@lists.sourceforge.net,
Dan Carpenter <d_carpenter@sbcglobal.net>
Subject: Re: [2.5] [Cool stuff] "checking" mode for kernel builds
Date: Tue, 27 May 2003 03:24:29 +0200 [thread overview]
Message-ID: <3ED2BE4D.4080005@gmx.net> (raw)
In-Reply-To: <Pine.LNX.4.44.0305261728520.15826-100000@home.transmeta.com>
[Linus: Sorry that your e-mail to me bounced. Was a provider screwup,
should be fixed now.]
[CC:ed kerneljanitors, who might be interested using it.
CC:ed Dan Carpenter, who mantains a set of tools similar to sparse, but
as a gcc patch at http://kbugs.org ]
Linus Torvalds wrote:
> Well, I guess I can just tell people about it. It's unfinished enough that
> I'm a bit embarrassed about some of it, but I've gotten the permission
> from Transmeta to make it open source, and it's actually been available
> for some time on "bk://kernel.bkbits.net/torvalds/sparse". I just didn't
> tell about it in public (although a few people have known about it).
>
> Be gentle with it. It does many things wrong, including (but limited
> to) enums, but it does a lot of things right too.
Playing with it right now.
> The biggest problem (apart from the things it does wrong) is that some
> parts of the kenel re-use the same structure to hold both user- and kernel
> pointers. That's a big no-no for the static semantic parser, since it's
> literally a _static_ type-checker, and doesn't know about dynamic
> differences.
>
> The main offender is the networking layer that sometimes keeps user
> pointers and sometimes kernel pointers in a "struct iovec". David has
> promised to look into this, and seemed confident that he can fix it
> easily.
>
> Most people who have used the tool actually like how it forces you to make
> it very _explicit_ whether you're using a user pointer or not. But I have
> to admit that I've grown tired of trying to look at all the uses and
> making sure which sparse warnings are valid and which aren't.
Dan? IIRC you have tools to tackle this issue in a distributed manner.
Regards,
Carl-Daniel
next prev parent reply other threads:[~2003-05-27 1:11 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-05-27 0:17 [2.5] [Cool stuff] "checking" mode for kernel builds Carl-Daniel Hailfinger
2003-05-27 0:25 ` John Anthony Kazos Jr.
2003-05-27 0:36 ` Linus Torvalds
2003-05-27 1:24 ` Carl-Daniel Hailfinger [this message]
2003-05-26 13:17 ` dan carpenter
2003-05-27 1:58 ` Miles Bader
2003-05-27 3:02 ` Aaron Lehmann
2003-05-27 3:23 ` Linus Torvalds
2003-05-27 4:47 ` Aaron Lehmann
2003-05-27 5:07 ` Linus Torvalds
2003-05-27 9:16 ` Ryan Anderson
2003-05-27 14:44 ` Linus Torvalds
2003-05-27 11:03 ` dep
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=3ED2BE4D.4080005@gmx.net \
--to=c-d.hailfinger.kernel.2003@gmx.net \
--cc=d_carpenter@sbcglobal.net \
--cc=kernel-janitor-discuss@lists.sourceforge.net \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@transmeta.com \
/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;
as well as URLs for NNTP newsgroup(s).