mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Kyle Moffett <mrmacman_g4@mac.com>
To: Adrian Bunk <bunk@stusta.de>
Cc: "Robert P. J. Day" <rpjday@mindspring.com>,
	LKML <linux-kernel@vger.kernel.org>,
	Oleg Verych <olecom@flower.upol.cz>
Subject: Re: why test for "__GNUC__"?
Date: Mon, 30 Oct 2006 00:08:42 -0500	[thread overview]
Message-ID: <FFAA1E76-B60F-46AD-B1A0-593517D8EDB1@mac.com> (raw)
In-Reply-To: <20061030033834.GJ27968@stusta.de>

On Oct 29, 2006, at 22:38:34, Adrian Bunk wrote:
>> for better or worse, i generally assume that whatever i'm looking  
>> at is there for a *reason* and i might spend some time puzzling  
>> over a bit of code until it finally dawns on me that it's just  
>> historical cruft that has no value.  it's not a bug, it just  
>> doesn't *do* anything anymore.
>>
>> in my case, it's sometimes easier to spot things like this since  
>> i'm following along in some book, like r. love's "linux kernel  
>> development."  so when he writes that the linux kernel is wedded  
>> to gcc, and yet i see tests for "__GNUC__" throughout the code, my  
>> little antenna stalks perk up a bit.
>
> Looking at it, it seems I might look through them - some of them  
> seem to be really pointless.

One other thing of note is that certain linux kernel headers _are_  
used by userspace (albeit in a number of cases legacy userspace), and  
as a result we need to ensure that they continue to build on the  
variety of compilers currently used in userspace.  Naturally this  
doesn't apply to everything, but see the recent threads involving  
(IIRC) some part of KDE and indirectly <linux/types.h>.  From what  
Linus has stated in the past it sounds like his goal is to make the  
user<=>libc interface completely 100% separated from the  
libc<=>kernel interface such that neither includes the other, but a  
lot of older userspace violates those assumptions.  As a result, if  
we want older versions of libc's to continue to work in various  
compilers with newer kernel headers we need to maintain some of that  
"compatibility cruft".

That said, if __GNUC__ is mentioned inside __KERNEL__ in anything  
other than a version test then it should probably be removed.  To  
that end these little macros in <linux/compiler.h> might make it a  
bit more obvious what's being tested and make it easier to grep for:

#ifdef __KERNEL__
# define GCC_VERSION ((__GNUC__ << 24) | \
	(__GNUC_MINOR__ << 16) | \
	(__GNUC_PATCHLEVEL__))
# define GCC_AT_LEAST(x,y,z) (GCC_VERSION >= (((x)<<24)|((y)<<16)|(z)))
# define GCC_OLDER_THAN(x,y,z) (!GCC_AT_LEAST(x,y,z))
#endif

> There's also the kernelnewbies list.
>
> But your emails are not as bad as you think - the email starting  
> this thread as well as your earlier emails regarding menu structure  
> etc. have some value (and they are better than many other questions  
> that hit this list...).

I personally tend to agree; seems like some of this cruft is just  
accepted status-quo because it would be so tedious and git-queue- 
blocking to go through and clean it all up.

Cheers,
Kyle Moffett


  reply	other threads:[~2006-10-30  5:09 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-10-29 11:13 Robert P. J. Day
2006-10-29 11:44 ` Jan Engelhardt
2006-10-29 12:44   ` Robert P. J. Day
2006-10-29 12:05     ` Alexey Dobriyan
2006-10-29 15:48       ` Robert P. J. Day
2006-10-29 16:17         ` Oleg Verych
2006-10-29 17:18           ` Adrian Bunk
2006-10-29 17:37             ` Robert P. J. Day
2006-10-29 18:23               ` Oleg Verych
2006-10-30  3:38               ` Adrian Bunk
2006-10-30  5:08                 ` Kyle Moffett [this message]
2006-10-29 16:59         ` Valdis.Kletnieks

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=FFAA1E76-B60F-46AD-B1A0-593517D8EDB1@mac.com \
    --to=mrmacman_g4@mac.com \
    --cc=bunk@stusta.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=olecom@flower.upol.cz \
    --cc=rpjday@mindspring.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

all inboxes | Powered by JetHome®