io.h ??

io.h ??

Post by QLYZ » Sun, 22 Jun 2003 10:15:08



Did I used an imcompatiable io.h ?

This is my first try on char driver (schar.c, sample code)

when /usr/src/linux-2.4.18-14/include/asm/io.h was included during
compiling, I got following error.
(I also tried /usr/include/asm/io.h and these are the only 2 asm/io.h
on my machine, RH8.0)

Thanks,
QLYZ

==== #include <asm/io.h> =====

gcc -D__KERNEL__ -I/usr/src/linux-2.4.18-14/include -DMODULE -Wall -O2
-c -o schar.o schar.c
In file included from /usr/src/linux-2.4.18-14/include/asm/io.h:47,
                  from schar.c:26:
/usr/src/linux-2.4.18-14/include/linux/vmalloc.h: In function `vmalloc':
/usr/src/linux-2.4.18-14/include/linux/vmalloc.h:35:
`boot_cpu_data_R0657d037' undeclared (first use in this function)
/usr/src/linux-2.4.18-14/include/linux/vmalloc.h:35: (Each undeclared
identifier is reported only once
/usr/src/linux-2.4.18-14/include/linux/vmalloc.h:35: for each function
it appears in.)
/usr/src/linux-2.4.18-14/include/linux/vmalloc.h: In function `vmalloc_dma':
/usr/src/linux-2.4.18-14/include/linux/vmalloc.h:44:
`boot_cpu_data_R0657d037' undeclared (first use in this function)
/usr/src/linux-2.4.18-14/include/linux/vmalloc.h: In function `vmalloc_32':
/usr/src/linux-2.4.18-14/include/linux/vmalloc.h:53:
`boot_cpu_data_R0657d037' undeclared (first use in this function)
schar.c: At top level:
schar.c:42: warning: initialization from incompatible pointer type
schar.c:43: warning: initialization from incompatible pointer type
schar.c:45: warning: initialization from incompatible pointer type
schar.c:46: warning: initialization from incompatible pointer type
schar.c:47: warning: initialization from incompatible pointer type
schar.c:48: warning: initialization from incompatible pointer type
schar.c:50: warning: initialization from incompatible pointer type
schar.c: In function `schar_mmap':
schar.c:168: structure has no member named `vm_offset'
schar.c: In function `init_module':
schar.c:450: warning: implicit declaration of function `MAP_NR'
schar.c:450: invalid type argument of `->'
schar.c:462: structure has no member named `fill_inode'
schar.c: In function `cleanup_module':
schar.c:483: invalid type argument of `->'
make: *** [schar.o] Error 1

====== #include "/usr/include/asm/io.h" =========

gcc -D__KERNEL__ -I/usr/src/linux-2.4.18-14/include -DMODULE -Wall -O2
-c -o schar.o schar.c
schar.c:42: warning: initialization from incompatible pointer type
schar.c:43: warning: initialization from incompatible pointer type
schar.c:45: warning: initialization from incompatible pointer type
schar.c:46: warning: initialization from incompatible pointer type
schar.c:47: warning: initialization from incompatible pointer type
schar.c:48: warning: initialization from incompatible pointer type
schar.c:50: warning: initialization from incompatible pointer type
schar.c: In function `schar_mmap':
schar.c:168: structure has no member named `vm_offset'
schar.c:181: warning: implicit declaration of function `virt_to_phys'
schar.c: In function `init_module':
schar.c:450: warning: implicit declaration of function `MAP_NR'
schar.c:450: invalid type argument of `->'
schar.c:462: structure has no member named `fill_inode'
schar.c: In function `cleanup_module':
schar.c:483: invalid type argument of `->'
make: *** [schar.o] Error 1

 
 
 

io.h ??

Post by QLYZ » Mon, 23 Jun 2003 04:56:07


Sorry, if I did not make myself clear.

The sample code which I tried was copied from a book. I assume that
there is no error in it. No where in the sample code it directly called
the function which produced "undeclared identifier" compiling error.

I guess that it may be caused by an incorrectly included head file,
the version?. I saw the same kind of errors when I experimented codes
of application programming.

Programming device driver is totally new to me. I tried the two
different io.h (/usr/src/linux-2.4.18-14/include/asm/io.h  and
/usr/include/asm/io.h ), problem still not solved. My programming
environment might not be set up properly. I don't know where to look at.

Can someone help me or point me to somewhere? How can I tell that is a
problem of code or a problem of environment?

Thanks a lot

QLYZ


> Did I used an imcompatiable io.h ?

> This is my first try on char driver (schar.c, sample code)

> when /usr/src/linux-2.4.18-14/include/asm/io.h was included during
> compiling, I got following error.
> (I also tried /usr/include/asm/io.h and these are the only 2 asm/io.h
> on my machine, RH8.0)

> Thanks,
> QLYZ

> ==== #include <asm/io.h> =====

> gcc -D__KERNEL__ -I/usr/src/linux-2.4.18-14/include -DMODULE -Wall -O2
> -c -o schar.o schar.c
> In file included from /usr/src/linux-2.4.18-14/include/asm/io.h:47,
>                  from schar.c:26:
> /usr/src/linux-2.4.18-14/include/linux/vmalloc.h: In function `vmalloc':
> /usr/src/linux-2.4.18-14/include/linux/vmalloc.h:35:
> `boot_cpu_data_R0657d037' undeclared (first use in this function)
> /usr/src/linux-2.4.18-14/include/linux/vmalloc.h:35: (Each undeclared
> identifier is reported only once
> /usr/src/linux-2.4.18-14/include/linux/vmalloc.h:35: for each function
> it appears in.)
> /usr/src/linux-2.4.18-14/include/linux/vmalloc.h: In function
> `vmalloc_dma':
> /usr/src/linux-2.4.18-14/include/linux/vmalloc.h:44:
> `boot_cpu_data_R0657d037' undeclared (first use in this function)
> /usr/src/linux-2.4.18-14/include/linux/vmalloc.h: In function `vmalloc_32':
> /usr/src/linux-2.4.18-14/include/linux/vmalloc.h:53:
> `boot_cpu_data_R0657d037' undeclared (first use in this function)
> schar.c: At top level:
> schar.c:42: warning: initialization from incompatible pointer type
> schar.c:43: warning: initialization from incompatible pointer type
> schar.c:45: warning: initialization from incompatible pointer type
> schar.c:46: warning: initialization from incompatible pointer type
> schar.c:47: warning: initialization from incompatible pointer type
> schar.c:48: warning: initialization from incompatible pointer type
> schar.c:50: warning: initialization from incompatible pointer type
> schar.c: In function `schar_mmap':
> schar.c:168: structure has no member named `vm_offset'
> schar.c: In function `init_module':
> schar.c:450: warning: implicit declaration of function `MAP_NR'
> schar.c:450: invalid type argument of `->'
> schar.c:462: structure has no member named `fill_inode'
> schar.c: In function `cleanup_module':
> schar.c:483: invalid type argument of `->'
> make: *** [schar.o] Error 1

> ====== #include "/usr/include/asm/io.h" =========

> gcc -D__KERNEL__ -I/usr/src/linux-2.4.18-14/include -DMODULE -Wall -O2
> -c -o schar.o schar.c
> schar.c:42: warning: initialization from incompatible pointer type
> schar.c:43: warning: initialization from incompatible pointer type
> schar.c:45: warning: initialization from incompatible pointer type
> schar.c:46: warning: initialization from incompatible pointer type
> schar.c:47: warning: initialization from incompatible pointer type
> schar.c:48: warning: initialization from incompatible pointer type
> schar.c:50: warning: initialization from incompatible pointer type
> schar.c: In function `schar_mmap':
> schar.c:168: structure has no member named `vm_offset'
> schar.c:181: warning: implicit declaration of function `virt_to_phys'
> schar.c: In function `init_module':
> schar.c:450: warning: implicit declaration of function `MAP_NR'
> schar.c:450: invalid type argument of `->'
> schar.c:462: structure has no member named `fill_inode'
> schar.c: In function `cleanup_module':
> schar.c:483: invalid type argument of `->'
> make: *** [schar.o] Error 1


 
 
 

io.h ??

Post by Wild Wizar » Mon, 23 Jun 2003 20:15:02



> Sorry, if I did not make myself clear.

> The sample code which I tried was copied from a book. I assume that
> there is no error in it. No where in the sample code it directly called
> the function which produced "undeclared identifier" compiling error.

> I guess that it may be caused by an incorrectly included head file,
> the version?. I saw the same kind of errors when I experimented codes
> of application programming.

<SNIP>

Quote:

>> ====== #include "/usr/include/asm/io.h" =========

>> gcc -D__KERNEL__ -I/usr/src/linux-2.4.18-14/include -DMODULE -Wall -O2
>> -c -o schar.o schar.c

try and remove the -I from this one you may be getting a mix of versions if
you have include paths with 2 sets of headers that are the same name

--
Happiness, n.:
        An agreeable sensation arising from contemplating the misery of
another.
                -- Ambrose Bierce, "The Devil's Dictionary"

 
 
 

io.h ??

Post by QLYZ » Tue, 24 Jun 2003 05:31:06


Yes, use #include "/usr/include/asm/io.h"
with    -I/usr/src/linux-2.4.18-14/include
did mess up. Let's focus on:
        -I/usr/src/linux-2.4.18-14/include

As mentioned in previous msg, undeclared
symbol: `boot_cpu_data_R0657d037'

but when I check /proc/ksyms, I do see it:
[localhost]$ /sbin/ksyms -a |grep boot
c0303160  boot_cpu_data_R0657d037
c0126160  register_reboot_notifier_R1cc6719a
c0126180  unregister_reboot_notifier_R3980aac1
c01263e0  sys_reboot_R5e38c4e6
[localhost]$

-QLYZ

==== #include <asm/io.h> =====

gcc -D__KERNEL__ -I/usr/src/linux-2.4.18-14/include -DMODULE -Wall -O2
-c -o schar.o schar.c
In file included from /usr/src/linux-2.4.18-14/include/asm/io.h:47,
                  from schar.c:26:
/usr/src/linux-2.4.18-14/include/linux/vmalloc.h: In function `vmalloc':
/usr/src/linux-2.4.18-14/include/linux/vmalloc.h:35:
`boot_cpu_data_R0657d037' undeclared (first use in this function)
/usr/src/linux-2.4.18-14/include/linux/vmalloc.h:35: (Each undeclared
identifier is reported only once
/usr/src/linux-2.4.18-14/include/linux/vmalloc.h:35: for each function
it appears in.)
/usr/src/linux-2.4.18-14/include/linux/vmalloc.h: In function `vmalloc_dma':
/usr/src/linux-2.4.18-14/include/linux/vmalloc.h:44:
`boot_cpu_data_R0657d037' undeclared (first use in this function)
/usr/src/linux-2.4.18-14/include/linux/vmalloc.h: In function `vmalloc_32':
/usr/src/linux-2.4.18-14/include/linux/vmalloc.h:53:
`boot_cpu_data_R0657d037' undeclared (first use in this function)
schar.c: At top level:
schar.c:42: warning: initialization from incompatible pointer type
schar.c:43: warning: initialization from incompatible pointer type
schar.c:45: warning: initialization from incompatible pointer type
schar.c:46: warning: initialization from incompatible pointer type
schar.c:47: warning: initialization from incompatible pointer type
schar.c:48: warning: initialization from incompatible pointer type
schar.c:50: warning: initialization from incompatible pointer type
schar.c: In function `schar_mmap':
schar.c:168: structure has no member named `vm_offset'
schar.c: In function `init_module':
schar.c:450: warning: implicit declaration of function `MAP_NR'
schar.c:450: invalid type argument of `->'
schar.c:462: structure has no member named `fill_inode'
schar.c: In function `cleanup_module':
schar.c:483: invalid type argument of `->'
make: *** [schar.o] Error 1



>>Sorry, if I did not make myself clear.

>>The sample code which I tried was copied from a book. I assume that
>>there is no error in it. No where in the sample code it directly called
>>the function which produced "undeclared identifier" compiling error.

>>I guess that it may be caused by an incorrectly included head file,
>>the version?. I saw the same kind of errors when I experimented codes
>>of application programming.

> <SNIP>

>>>====== #include "/usr/include/asm/io.h" =========

>>>gcc -D__KERNEL__ -I/usr/src/linux-2.4.18-14/include -DMODULE -Wall -O2
>>>-c -o schar.o schar.c

> try and remove the -I from this one you may be getting a mix of versions if
> you have include paths with 2 sets of headers that are the same name

 
 
 

io.h ??

Post by Jens.Toerr.. » Tue, 24 Jun 2003 19:57:43



> Yes, use #include "/usr/include/asm/io.h"
> with       -I/usr/src/linux-2.4.18-14/include
> did mess up. Let's focus on:
>    -I/usr/src/linux-2.4.18-14/include

Never use /usr/include/linux and /usr/include/asm. Some time ago they
were supposed to be symbolic links to the kernel headers, but this
changed and nowadays they are normal directories with header files
that normally are out of sync ith the real header files.

/usr/src/linux-2.4.18-14/include is ok when you really are using
a linux-2.4.18-14 kernel. But to be able to automatically pick the
headers for the currently kernel you better should use

-I/lib/modules/`uname -r`/build/include

The `uname -r` automatically translates to the name of the currently
running kernel (just try it on the command line).

Quote:> As mentioned in previous msg, undeclared
> symbol: `boot_cpu_data_R0657d037'
> but when I check /proc/ksyms, I do see it:
> [localhost]$ /sbin/ksyms -a |grep boot
> c0303160  boot_cpu_data_R0657d037
> c0126160  register_reboot_notifier_R1cc6719a
> c0126180  unregister_reboot_notifier_R3980aac1
> c01263e0  sys_reboot_R5e38c4e6
> [localhost]$

Do you have something like

#include <linux/config.h>

#if defined( CONFIG_MODVERSIONS ) && ! defined( MODVERSIONS )
#define MODVERSIONS
#endif

#if defined( MODVERSIONS )
#include <linux/modversions.h>
#endif

at the start of your module? This is needed to figure out if symbol
versioning is switched on for the kernel (which you obviously have,
the '_R1cc6719a' bit at the end of the function names is a clear
indication). Thus without including <linux/modversions.h> you will
get this kind of errors. On the other hand, you shouldn't include
the file when symbol versioning isn't switched on, thus the #if
stuff before.

Quote:> ==== #include <asm/io.h> =====
> gcc -D__KERNEL__ -I/usr/src/linux-2.4.18-14/include -DMODULE -Wall -O2
> -c -o schar.o schar.c
> In file included from /usr/src/linux-2.4.18-14/include/asm/io.h:47,
>                   from schar.c:26:
> /usr/src/linux-2.4.18-14/include/linux/vmalloc.h: In function `vmalloc':
> /usr/src/linux-2.4.18-14/include/linux/vmalloc.h:35:
> `boot_cpu_data_R0657d037' undeclared (first use in this function)
> /usr/src/linux-2.4.18-14/include/linux/vmalloc.h:35: (Each undeclared
> identifier is reported only once
> /usr/src/linux-2.4.18-14/include/linux/vmalloc.h:35: for each function
> it appears in.)
> /usr/src/linux-2.4.18-14/include/linux/vmalloc.h: In function `vmalloc_dma':
> /usr/src/linux-2.4.18-14/include/linux/vmalloc.h:44:
> `boot_cpu_data_R0657d037' undeclared (first use in this function)
> /usr/src/linux-2.4.18-14/include/linux/vmalloc.h: In function `vmalloc_32':
> /usr/src/linux-2.4.18-14/include/linux/vmalloc.h:53:
> `boot_cpu_data_R0657d037' undeclared (first use in this function)
> schar.c: At top level:
> schar.c:42: warning: initialization from incompatible pointer type

That's probably some additional error. But without seeing the code
it's hard to figure out what's going wrong. Perhaps it's just a
forgotten semicolon, but....

                                           Regards, Jens
--
      _  _____  _____

  _  | |  | |    | |
 | |_| |  | |    | |          http://www.physik.fu-berlin.de/~toerring
  \___/ens|_|homs|_|oerring

 
 
 

io.h ??

Post by QLYZ » Wed, 25 Jun 2003 11:08:46



> Never use /usr/include/linux and /usr/include/asm. Some time ago they
> were supposed to be symbolic links to the kernel headers, but this
> changed and nowadays they are normal directories with header files
> that normally are out of sync ith the real header files.

> /usr/src/linux-2.4.18-14/include is ok when you really are using
> a linux-2.4.18-14 kernel. But to be able to automatically pick the
> headers for the currently kernel you better should use

> -I/lib/modules/`uname -r`/build/include

I try your recommendation, which generates exactlly the same path
as it was hard coded before (in makefile)

http://www.kernelnewbies.org/faq/index.php3#compmod, referred by
Kasper is also reviewed. It does mention that the gcc should has
the same version as used for kernel compilation, here is my gcc/kernel

[localhost]$ cat /proc/version

version 3.2 20020903 (Red Hat Linux 8.0 3.2-7)) #1 Wed Sep 4 13:35:50
EDT 2002

[localhost]$ rpm -qi gcc
Name        : gcc                          Relocations: (not relocateable)
Version     : 3.2                               Vendor: Red Hat, Inc.
Release     : 7                             Build Date: Tue 03 Sep 2002
08:04:33 PM PDT
Install date: Sat 12 Oct 2002 07:12:59 AM PDT      Build Host:
daffy.perf.redhat.com
Group       : Development/Languages         Source RPM: gcc-3.2-7.src.rpm
...

looks the same

Quote:

> Do you have something like

> #include <linux/config.h>

> #if defined( CONFIG_MODVERSIONS ) && ! defined( MODVERSIONS )
> #define MODVERSIONS
> #endif

> #if defined( MODVERSIONS )
> #include <linux/modversions.h>
> #endif

test code is copied from "Beginning Linux Programming, 2nd ed."
I tried .. && ! define( MODVERSIONS ) also, doesn't make difference

/*
  *      Example of simple character device driver (schar)
  */

#include <linux/module.h>

#if defined(CONFIG_SMP)
#define __SMP__
#endif

#if defined(CONFIG_MODVERSIONS)
#define MODVERSIONS
#include <linux/modversions.h>
#endif

#include <linux/kernel.h>
#include <linux/sched.h>
#include <linux/timer.h>        /* for timers */
#include <linux/fs.h>           /* file modes and device registration */
#include <linux/poll.h>         /* for poll */
#include <linux/wrapper.h>      /* mem_map_reserve,mem_map_unreserve */
#include <linux/proc_fs.h>
#include <linux/sysctl.h>
#include <linux/init.h>

#include <asm/io.h>

/* module declaration start here */
...

Does this "undeclare" matter? or it is just a warnning?
I may need to look at the other erro which fail the compiling ...

 
 
 

io.h ??

Post by Jens.Toerr.. » Wed, 25 Jun 2003 16:28:19




>> -I/lib/modules/`uname -r`/build/include
> I try your recommendation, which generates exactlly the same path
> as it was hard coded before (in makefile)

It should as long as you don't install a new kernel and then
forget to change the makefile for your module...

Quote:> test code is copied from "Beginning Linux Programming, 2nd ed."
> I tried .. && ! define( MODVERSIONS ) also, doesn't make difference

The "&& ! define( MODVERSIONS )" is only there to keep the compiler
from uttering a useless warning in case MODVERSIONS is already
defined.

Quote:> #include <linux/module.h>
> #if defined(CONFIG_SMP)
> #define __SMP__
> #endif
> #if defined(CONFIG_MODVERSIONS)
> #define MODVERSIONS
> #include <linux/modversions.h>
> #endif
> Does this "undeclare" matter? or it is just a warnning?
> I may need to look at the other erro which fail the compiling ...

You must include <linux/module.h> only after <linux/modversions.h>.
I had exactly the same problem once, i.e. having problems with
`boot_cpu_data' being not found, and it took me quite some time
to figure out why (there are several layers of macros in half a
dozen files involved). That's also why you then need to include
<linux/config.h> yourself: <linux/modules.h> does include it,
but you need to know if CONFIG_MODVERSION is defined before in
order to find out if you need to include <linux/modversions.h>.

So you should use something like

#include <linux/config.h>

#if defined( CONFIG_MODVERSIONS ) && ! defined( MODVERSIONS )
#define MODVERSIONS
#endif

#if defined( MODVERSIONS )
#include <linux/modversions.h>
#endif

#include <linux/module.h>

That's also the way Rubini and Corbet write it in their book
"Linux Device Drivers", 2nd ed., p. 314f:

"<linux/modversions.h> must be included before any other header file,
so place it first if you put it into your driver source."

                                Regards, Jens
--
      _  _____  _____

  _  | |  | |    | |
 | |_| |  | |    | |          http://www.physik.fu-berlin.de/~toerring
  \___/ens|_|homs|_|oerring

 
 
 

io.h ??

Post by QLYZ » Thu, 26 Jun 2003 13:36:47



> You must include <linux/module.h> only after <linux/modversions.h>.
> I had exactly the same problem once, i.e. having problems with
> `boot_cpu_data' being not found, and it took me quite some time
> to figure out why (there are several layers of macros in half a
> dozen files involved). That's also why you then need to include
> <linux/config.h> yourself: <linux/modules.h> does include it,
> but you need to know if CONFIG_MODVERSION is defined before in
> order to find out if you need to include <linux/modversions.h>.

> So you should use something like

> #include <linux/config.h>

> #if defined( CONFIG_MODVERSIONS ) && ! defined( MODVERSIONS )
> #define MODVERSIONS
> #endif

> #if defined( MODVERSIONS )
> #include <linux/modversions.h>
> #endif

> #include <linux/module.h>

> That's also the way Rubini and Corbet write it in their book
> "Linux Device Drivers", 2nd ed., p. 314f:

> "<linux/modversions.h> must be included before any other header file,
> so place it first if you put it into your driver source."

>                                 Regards, Jens

It is amazing !!
I must share the same joy which you had before,
thank you, Jens.

Q.