From: Sam Ravnborg <sam@ravnborg.org>
To: Ismail Donmez <ismail@pardus.org.tr>
Cc: Kyle Moffett <mrmacman_g4@mac.com>, Andrew Morton <akpm@osdl.org>,
David Woodhouse <dwmw2@infradead.org>,
LKML <linux-kernel@vger.kernel.org>,
mchehab@infradead.org
Subject: Re: __STRICT_ANSI__ checks in headers
Date: Sun, 1 Oct 2006 11:14:11 +0200 [thread overview]
Message-ID: <20061001091411.GA9647@uranus.ravnborg.org> (raw)
In-Reply-To: <200610011034.57158.ismail@pardus.org.tr>
On Sun, Oct 01, 2006 at 10:34:56AM +0300, Ismail Donmez wrote:
> On Sunday 01 October 2006 08:20, Kyle Moffett wrote:
> > On Oct 01, 2006, at 00:53:43, Andrew Morton wrote:
> [...]
> > > Bisection shows that this patch causes these depmod warnings:
> > >
> > > WARNING: "snd_card_disconnect" [sound/usb/usx2y/snd-usb-usx2y.ko]
> > > has no CRC!
> > > [etc]
> > >
> > > I don't know why that would happen.
> > >
> > > From: Ismail Donmez <ismail@pardus.org.tr>
> > >
> > > __STRICT_ANSI__ usage in types.h header results in compile errors
> > > for some userspace packages[1] when used with gcc -ansi flag. With
> > > the suggestion of Kyle Moffett I replace strict ansi checks with
> > > __extension__ to tell gcc not to error or warn on gcc extensions.
> > > Compile tested on x86 with 2.6.18.
> >
> > Best guess: Depmod does some kind of funny type-based expansion and
> > hashing of the symbols which doesn't understand the "__extension__"
> > keyword. Probably the simplest thing to do is to add "-
> > D__extension__=" to the depmod preprocessing flags. Alternatively
> > you could teach depmod to completely ignore the __extension__ keyword
> > when it shows up in the sources, but the former seems like it would
> > be much simpler.
> >
> > Just thinking about it we probably also need to educate sparse about
> > __extension__ too. Perhaps somebody could also add an sparse flag to
> > make it warn about nonportable constructs in exported header files.
> >
> > I'd submit a patch but my knowledge of kernel makefiles and depmod is
> > somewhere between zero and none, exclusive.
>
> Thanks, I will have a look at it.
I assume you will same errors from the in-kernel modpost.
If you do not do so then there is some inconsistency between depmod
and modpost that ougth to be fixed.
I'm not up to the task atm - busy with my day job and travelling a lot
Sam
next prev parent reply other threads:[~2006-10-01 9:14 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <200609150901.33644.ismail@pardus.org.tr>
2006-09-15 6:42 ` __STRICT_ANSI__ checks in headers David Woodhouse
2006-09-15 13:27 ` Kyle Moffett
[not found] ` <200609211200.25214.ismail@pardus.org.tr>
2006-09-21 9:02 ` David Woodhouse
2006-09-21 12:53 ` Ismail Donmez
2006-09-28 7:03 ` Ismail Donmez
2006-09-28 7:06 ` David Woodhouse
2006-09-28 7:30 ` Ismail Donmez
2006-10-01 4:53 ` Andrew Morton
2006-10-01 5:20 ` Kyle Moffett
2006-10-01 7:34 ` Ismail Donmez
2006-10-01 9:14 ` Sam Ravnborg [this message]
2006-10-01 12:54 ` Ismail Donmez
2006-10-05 8:16 ` Ismail Donmez
2006-10-05 8:56 ` Kyle Moffett
2006-10-06 8:26 ` David Woodhouse
2006-10-07 7:17 ` Kyle Moffett
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=20061001091411.GA9647@uranus.ravnborg.org \
--to=sam@ravnborg.org \
--cc=akpm@osdl.org \
--cc=dwmw2@infradead.org \
--cc=ismail@pardus.org.tr \
--cc=linux-kernel@vger.kernel.org \
--cc=mchehab@infradead.org \
--cc=mrmacman_g4@mac.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.