since (as i understand it) the linux kernel *requires* gcc these
days, what is the point of the numerous preprocessor tests of the
form:
#ifdef __GNUC__
and its variations?
under the circumstances, aren't all those tests redundant?
rday
> since (as i understand it) the linux kernel *requires* gcc these
>days, what is the point of the numerous preprocessor tests of the
>form:
ICC is said to work too.
-`J'
--
On Sun, 29 Oct 2006, Jan Engelhardt wrote:
>
> > since (as i understand it) the linux kernel *requires* gcc these
> >days, what is the point of the numerous preprocessor tests of the
> >form:
>
> ICC is said to work too.
ah, i was not aware of that. but does that mean that ICC is (or will
be) *officially* supported? or does it just *happen* to work at the
moment with no guarantees of future compatibility?
rday
p.s. is there, in fact, any part of the kernel source tree that has a
preprocessor directive to identify the use of ICC? just curious.
On Sun, Oct 29, 2006 at 07:44:18AM -0500, Robert P. J. Day wrote:
> p.s. is there, in fact, any part of the kernel source tree that has a
> preprocessor directive to identify the use of ICC? just curious.
Please, do
ls include/linux/compiler-*
On Sun, 29 Oct 2006, Alexey Dobriyan wrote:
> On Sun, Oct 29, 2006 at 07:44:18AM -0500, Robert P. J. Day wrote:
> > p.s. is there, in fact, any part of the kernel source tree that has a
> > preprocessor directive to identify the use of ICC? just curious.
>
> Please, do
>
> ls include/linux/compiler-*
but according to compiler.h:
/* Intel compiler defines __GNUC__. So we will overwrite implementations
* coming from above header files here
*/
so even ICC will define __GNUC__, which means that testing for
__GNUC__ is *still*, under the circumstances, redundant, isn't that
right?
rday
Hallo.
On 2006-10-29, Robert P. J. Day wrote:
> On Sun, 29 Oct 2006, Alexey Dobriyan wrote:
>
>> On Sun, Oct 29, 2006 at 07:44:18AM -0500, Robert P. J. Day wrote:
>> > p.s. is there, in fact, any part of the kernel source tree that has a
>> > preprocessor directive to identify the use of ICC? just curious.
>>
>> Please, do
>>
>> ls include/linux/compiler-*
>
> but according to compiler.h:
>
> /* Intel compiler defines __GNUC__. So we will overwrite implementations
> * coming from above header files here
> */
>
> so even ICC will define __GNUC__, which means that testing for
> __GNUC__ is *still*, under the circumstances, redundant, isn't that
> right?
Does it introduce bugs? Just think of it as legacy, if you want.
And if you can, please, help with development or bugs, not this.
____
On Sun, 29 Oct 2006 10:48:43 EST, "Robert P. J. Day" said:
> On Sun, 29 Oct 2006, Alexey Dobriyan wrote:
>
> > On Sun, Oct 29, 2006 at 07:44:18AM -0500, Robert P. J. Day wrote:
> > > p.s. is there, in fact, any part of the kernel source tree that has a
> > > preprocessor directive to identify the use of ICC? just curious.
> >
> > Please, do
> >
> > ls include/linux/compiler-*
>
> but according to compiler.h:
>
> /* Intel compiler defines __GNUC__. So we will overwrite implementations
> * coming from above header files here
> */
>
> so even ICC will define __GNUC__, which means that testing for
> __GNUC__ is *still*, under the circumstances, redundant, isn't that
> right?
The Intel compiler started defining __GNUC__ fairly recently (within the
last 2-3 years). Most likely the tests date from long ago and far away,
before it did so.
On Sun, Oct 29, 2006 at 04:17:51PM +0000, Oleg Verych wrote:
>...
> On 2006-10-29, Robert P. J. Day wrote:
>>...
> And if you can, please, help with development or bugs, not this.
Cleanup of the kernel source is also a valuable task (and as a side
effect it even sometimes finds bugs).
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
On Sun, 29 Oct 2006, Adrian Bunk wrote:
> On Sun, Oct 29, 2006 at 04:17:51PM +0000, Oleg Verych wrote:
> >...
> > On 2006-10-29, Robert P. J. Day wrote:
> >>...
> > And if you can, please, help with development or bugs, not this.
>
> Cleanup of the kernel source is also a valuable task (and as a side
> effect it even sometimes finds bugs).
on that note, i realize that most of my postings are addressing
nitpicky/aesthetic issues that don't actually *hurt* anything, but for
someone who's clawing his way through the kernel code for the first
time, a lot of it is unnecessarily confusing.
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.
having someone point out that ICC is also an option clarifies that
briefly ... until i notice that ICC *also* defines __GNUC__ equal to
4, so i'm back to being confused. (as an aside, i downloaded the most
recent ICC earlier today and did a test compile of the latest git
pull. man, the stuff under scripts/ needs to be cleaned something
fierce. :-)
then there's the apparently historical stuff related to "signed"
versus "__signed" versus "__signed__". sure, it all works, but it's
needlessly complicated and verbose and might also lead someone astray
trying to figure out what the rationale is. (and don't even get me
started on semaphores. :-)
in any event, i'm most emphatically *not* (yet) at the level where i'm
going to be able to contribute bleeding-edge code. but i'm certainly
capable of poring over the *existing* code and pointing out the places
that might lead someone to mutter, "what the hell...?"
maybe there's a better forum for me to make these observations. i'm
open to suggestions. i've made a list of these observations and i'd
be happy to send them to the right person.
rday
On 2006-10-29, Robert P. J. Day <[email protected]> wrote:
> On Sun, 29 Oct 2006, Adrian Bunk wrote:
>
>> On Sun, Oct 29, 2006 at 04:17:51PM +0000, Oleg Verych wrote:
>> >...
>> > On 2006-10-29, Robert P. J. Day wrote:
>> >>...
>> > And if you can, please, help with development or bugs, not this.
>>
> Cleanup of the kernel source is also a valuable task (and as a side
> effect it even sometimes finds bugs).
Accept, Adrian, not in this case (;.
> in any event, i'm most emphatically *not* (yet) at the level where i'm
> going to be able to contribute bleeding-edge code. but i'm certainly
> capable of poring over the *existing* code and pointing out the places
> that might lead someone to mutter, "what the hell...?"
>
> maybe there's a better forum for me to make these observations. i'm
> open to suggestions. i've made a list of these observations and i'd
> be happy to send them to the right person.
Well, consult <http://kerneljanitors.org/>, or start to send patches.
My first step was to open top Makefile with emacs, and just to save file
(without even editing it). Resulting patch broke some old `make' on
Andrew Morton's test field:
<http://marc.theaimsgroup.com/?l=linux-mm-commits&m=116198944205036&w=2>
That means top Makefile is writen with errors, somebody doesn't edit
kernel versions with "decent editor" (;
But it's working for many years and kernel versions. This yields, that
linux kernel is written by open source developers with help of users.
And it's written for to do the job. ^1
Do not expect much, just help with what you can. But i would suggest to
search archives, read sources (1.0, 2.0. 2.2, 2.4) + apply ^1 before any
questions.
____
On Sun, Oct 29, 2006 at 12:37:36PM -0500, Robert P. J. Day wrote:
> On Sun, 29 Oct 2006, Adrian Bunk wrote:
>
> > On Sun, Oct 29, 2006 at 04:17:51PM +0000, Oleg Verych wrote:
> > >...
> > > On 2006-10-29, Robert P. J. Day wrote:
> > >>...
> > > And if you can, please, help with development or bugs, not this.
> >
> > Cleanup of the kernel source is also a valuable task (and as a side
> > effect it even sometimes finds bugs).
>
> on that note, i realize that most of my postings are addressing
> nitpicky/aesthetic issues that don't actually *hurt* anything, but for
> someone who's clawing his way through the kernel code for the first
> time, a lot of it is unnecessarily confusing.
>
> 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.
> in any event, i'm most emphatically *not* (yet) at the level where i'm
> going to be able to contribute bleeding-edge code. but i'm certainly
> capable of poring over the *existing* code and pointing out the places
> that might lead someone to mutter, "what the hell...?"
>
> maybe there's a better forum for me to make these observations. i'm
> open to suggestions. i've made a list of these observations and i'd
> be happy to send them to the right person.
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...).
> rday
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
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