public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: smitchel <smitchel@bnin.net>
To: linux-kernel@vger.kernel.org
Subject: possible mistake in linux kernel header file -- kernel: 2.6.16.29 file: mod_devicetable.h
Date: Tue, 27 Mar 2007 23:28:31 -0400	[thread overview]
Message-ID: <4609E0DF.5020508@bnin.net> (raw)

I am not sure where to post this, maybe you can direct me what to do, if 
anything.

We have two computers running slackware for amd64 version 11.0.
Tonight we compiled mplayer on each of the systems.

On the first, everything compiled fine--it has a core 2 duo cpu and is 
running a stock kernel off the install DVD for slackware-amd64.
it is kernel 2.6.16.29.

On the second it would not compile, and it has dual opteron 250 cpus and 
is running a kernel that we compiled to add some things to
for sound, etc.   This was from a kernel source that we downloaded a few 
days ago.
it is kernel 2.6.16.29--same as first machine.

The error is stopping in the file /usr/include/linux/mod_devicetable.h.

It appears that there are 4 extra lines that have been added to the  
mod_devicetable.h that was part of the kernel source that we downloaded.
They are in the first screenful of the file:

#ifdef __KERNEL__
#include <linux/types.h>
typedef unsigned long kernel_ulong_t;
#endif

They are not in the same file in the kernel source from the slackware 
amd-64 install DVD. (<linux/types.h> included somewhere else?)

Googling we found:
__KERNEL__ is defined for programs that run in kernel mode instead of 
user programs (whatever that means).

A few lines later in mod_devicetable.h it uses the type kernel_ulong_t 
(in the same file--what if the ifdef path is not taken?)

We thought that for the header file to be self-consistent, the typedef 
statement should be defined in either case (__Kernel__ defined or not).
So we copied that line out of the ifdef to just below it.
Well that got rid of the type undefined error that occured during make.

We still got a bunch of errors, mostly every word in the 
mod_devicetable.h was individually "not understood" after the 
ifdef-endif lines.

Not wanting to break something somewhere else by defining __KERNEL__ 
when we don't even understand what it does...we copied the
include statement for <linux/types.h> after the endif, so basically both 
lines inside the ifdef are executed all the time.

Now it compiles fine.

Could this be a bug in a kernel header file?  It has to be. if you don't 
have __KERNEL__ defined, then the header file is broken because it uses
the type kernel_ulong_t just a few lines later.

Steve Mitchell
Byrel Mitchell
smitchel@bnin.net



             reply	other threads:[~2007-03-28  3:43 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-03-28  3:28 smitchel [this message]
     [not found] <fa.oyzxCetQPxeJg2D2eekG0Gighs4@ifi.uio.no>
2007-03-28 23:09 ` possible mistake in linux kernel header file -- kernel: 2.6.16.29 file: mod_devicetable.h Robert Hancock

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=4609E0DF.5020508@bnin.net \
    --to=smitchel@bnin.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