Problems compiling kernel modules

Problems compiling kernel modules

[Lei Yang]

Hi all,

I was trying to compile a kernel module with kbuild. The module 'test.c' 
include a header file 'fred.h' and there is a "#include <stdio.h>" in 
'fred.h'.

Makefile looks like:

------------------------------------------------------------------------
ifneq ($(KERNELRELEASE),)
obj-m       := test.o

else
KDIR        := /usr/src/linux
PWD         := $(shell pwd)

default:
	$(MAKE) -C $(KDIR) SUBDIRS=$(PWD) modules
	

clean:
	rm -f *.o *.ko *.mod.c *.mod.o \
	.test.o.cmd .test.ko.cmd .test.mod.o.cmd
	rm -rf .tmp_versions
endif

-------------------------------------------------------------------------
But upon compiling, there would be errors like this:
In file included from /home/lei/test.c:49:
/home/lei/fred.h:4:19: stdio.h: No such file or directory

and a lot of undeclared names follow which I assume is from stdio.h.

Could anyone point out what's wrong here?

TIA!

Lei

Re: Problems compiling kernel modules

[Lei Yang]

Sam Ravnborg wrote:
> On Sat, Aug 21, 2004 at 03:24:12PM -0400, Lei Yang wrote:
> 
>>Hi all,
>>
>>I was trying to compile a kernel module with kbuild. The module 'test.c' 
>>include a header file 'fred.h' and there is a "#include <stdio.h>" in 
>>'fred.h'.
>>
>>Makefile looks like:
>>
>>------------------------------------------------------------------------
>>ifneq ($(KERNELRELEASE),)
>>obj-m       := test.o
>>
>>else
>>KDIR        := /usr/src/linux
>>PWD         := $(shell pwd)
>>
>>default:
>>	$(MAKE) -C $(KDIR) SUBDIRS=$(PWD) modules
>>	
>>
>>clean:
> 
> For 2.6.7 (or 2.6.6) you do not need to specify your own clean: rule.
> 
> 
>>But upon compiling, there would be errors like this:
>>In file included from /home/lei/test.c:49:
>>/home/lei/fred.h:4:19: stdio.h: No such file or directory
> 
> The kernel does not provide you with a stdio.h header, so therefore you
> cannot find it neither use functionality from it.

You mean I can't use stdio.h at all?

But what if I really need to? Is there anything I can do?

> 	Sam

Re: Problems compiling kernel modules

[Lei Yang]

Sam Ravnborg wrote:
> On Sat, Aug 21, 2004 at 03:45:38PM -0400, Lei Yang wrote:
> 
>>You mean I can't use stdio.h at all?
> 
> Correct.
> 
>>But what if I really need to? Is there anything I can do?
> 
> Try to explain what you need. Then maybe someone on the list can help you.

I need to do File I/O operation and I need to use streams.

Thanks,
Lei

Re: Problems compiling kernel modules

[viro]

On Sat, Aug 21, 2004 at 03:45:38PM -0400, Lei Yang wrote:
> You mean I can't use stdio.h at all?

Not in the kernel code.
 
> But what if I really need to?

Then you are really out of luck.

> Is there anything I can do?

A lot of things - hopefully your life is not reduced to trying to write
stdio-dependent kernel modules...

Re: Problems compiling kernel modules

[Lee Revell]

On Sat, 2004-08-21 at 15:45, Lei Yang wrote:

> You mean I can't use stdio.h at all?
> 
> But what if I really need to?

LOL, the above needs to go in the FAQ.

Lee

Re: Problems compiling kernel modules

[Lei Yang]

What about multi-file module?

Say test.c doesn't include stdio.h, while there is some other .c file 
which is to be compiled and linked into test.ko, include stdio?

Would that work?

TIA!
Lei
Sam Ravnborg wrote:
> On Sat, Aug 21, 2004 at 03:45:38PM -0400, Lei Yang wrote:
> 
>>You mean I can't use stdio.h at all?
> 
> Correct.
> 
>>But what if I really need to? Is there anything I can do?
> 
> Try to explain what you need. Then maybe someone on the list can help you.
> 
> 	Sam

Re: Problems compiling kernel modules

[Lee Revell]

On Sat, 2004-08-21 at 16:46, Lei Yang wrote:
> What about multi-file module?
> 
> Say test.c doesn't include stdio.h, while there is some other .c file 
> which is to be compiled and linked into test.ko, include stdio?
> 
> Would that work?
> 

Are you just trying to print from a kernel module?  Use printk.

The kernel does not really have its own standard input and standard
output - the kernel manages those things for processes.

Lee

Re: Problems compiling kernel modules

[Alex Goddard]

On Sat, 21 Aug 2004, Lei Yang wrote:

> What about multi-file module?
>
> Say test.c doesn't include stdio.h, while there is some other .c file which 
> is to be compiled and linked into test.ko, include stdio?
>
> Would that work?
>
> TIA!
> Lei

You can't use userspace headers in the kernel.  That's why the kernel has 
its own set with things like printk(), etc, etc.  What is it that you're 
trying to do and why does it need file i/o?

-- 
Alex Goddard
agoddard at purdue dot edu

Re: Problems compiling kernel modules

[Sam Ravnborg]

On Sat, Aug 21, 2004 at 03:24:12PM -0400, Lei Yang wrote:
> Hi all,
> 
> I was trying to compile a kernel module with kbuild. The module 'test.c' 
> include a header file 'fred.h' and there is a "#include <stdio.h>" in 
> 'fred.h'.
> 
> Makefile looks like:
> 
> ------------------------------------------------------------------------
> ifneq ($(KERNELRELEASE),)
> obj-m       := test.o
> 
> else
> KDIR        := /usr/src/linux
> PWD         := $(shell pwd)
> 
> default:
> 	$(MAKE) -C $(KDIR) SUBDIRS=$(PWD) modules
> 	
> 
> clean:
For 2.6.7 (or 2.6.6) you do not need to specify your own clean: rule.

> But upon compiling, there would be errors like this:
> In file included from /home/lei/test.c:49:
> /home/lei/fred.h:4:19: stdio.h: No such file or directory
The kernel does not provide you with a stdio.h header, so therefore you
cannot find it neither use functionality from it.

	Sam

Re: Problems compiling kernel modules

[Sam Ravnborg]

On Sat, Aug 21, 2004 at 03:45:38PM -0400, Lei Yang wrote:
> 
> You mean I can't use stdio.h at all?
Correct.
> 
> But what if I really need to? Is there anything I can do?
Try to explain what you need. Then maybe someone on the list can help you.

	Sam

Re: Problems compiling kernel modules

[Lei Yang]

Hi friends,

I've askeed questions about errors compiling kernel modules caused by 
including <stdio.h> and got some very helpful info here.

I changed those I/O stream and file operation in the code and get the 
module compiled, however, there would be warnings like

In file included from /home/lei/modules/test.c:49:
/home/lei/modules/Kcomp.h:21: warning: function declaration isn't a 
prototype
/home/lei/modules/Kcomp.h:27: warning: function declaration isn't a 
prototype
/home/lei/modules/Kcomp.h:69: warning: function declaration isn't a 
prototype

And the no prototype fuction looks like

int preset() // with no arguments
{
	p = &nodes[0][0];
	return 0;
}


So when I tried to install the module with insmod ./test.ko ,
there would be an error,

insmod: error inserting './test.ko': -1 Unknown symbol in module

Could anyone tell me what is wrong here? Is that because of the no 
prototype function declaration?

TIA
Lei

Lee Revell wrote:
> On Sat, 2004-08-21 at 16:46, Lei Yang wrote:
> 
>>What about multi-file module?
>>
>>Say test.c doesn't include stdio.h, while there is some other .c file 
>>which is to be compiled and linked into test.ko, include stdio?
>>
>>Would that work?
>>
> 
> 
> Are you just trying to print from a kernel module?  Use printk.
> 
> The kernel does not really have its own standard input and standard
> output - the kernel manages those things for processes.
> 
> Lee
> 

Re: Problems compiling kernel modules

[Richard B. Johnson]

On Mon, 23 Aug 2004, Lei Yang wrote:

> Hi friends,
>
> I've askeed questions about errors compiling kernel modules caused by
> including <stdio.h> and got some very helpful info here.
>
> I changed those I/O stream and file operation in the code and get the
> module compiled, however, there would be warnings like
>
> In file included from /home/lei/modules/test.c:49:
> /home/lei/modules/Kcomp.h:21: warning: function declaration isn't a
> prototype
> /home/lei/modules/Kcomp.h:27: warning: function declaration isn't a
> prototype
> /home/lei/modules/Kcomp.h:69: warning: function declaration isn't a
> prototype
>
> And the no prototype fuction looks like
>
> int preset() // with no arguments
> {
> 	p = &nodes[0][0];
> 	return 0;
> }
>

A function looks like this:

int present()
{

}

A prototype for the same function looks like this:

int present(void);

Functions always have "{}". Prototypes never do.
-- Yes there's some troll who might cite some obscure
case... ignore them.

If you compile above a certain warning-level, then prototypes
are required. The prototype usually goes in header files
and the function (the actual code) goes in the source files.

>
> So when I tried to install the module with insmod ./test.ko ,
> there would be an error,
>
> insmod: error inserting './test.ko': -1 Unknown symbol in module
>
> Could anyone tell me what is wrong here? Is that because of the no
> prototype function declaration?
>

Do `depmod -e test.ko` to see what it's complaining about. You
can see all the symbols by using `nm`. Try it. Your code
probably didn't define the necessary stuff to make a module.
You need to look at a typical module (driver) that comes with the
kernel. Just find one of the shortest ".c" files in the driver
tree.


Cheers,
Dick Johnson
Penguin : Linux version 2.4.26 on an i686 machine (5570.56 BogoMips).
            Note 96.31% of all statistics are fiction.

Re: Problems compiling kernel modules

[Lei Yang]

Richard B. Johnson wrote:

> Do `depmod -e test.ko` to see what it's complaining about. You
> can see all the symbols by using `nm`. Try it. Your code
> probably didn't define the necessary stuff to make a module.
> You need to look at a typical module (driver) that comes with the
> kernel. Just find one of the shortest ".c" files in the driver
> tree.

Thanks! I did less /var/log/messages, and got the unknown symbols
Unknown symbol __divsf3
Unknown symbol __fixsfsi
Unknown symbol __subsf3
Unknown symbol __floatsisf
Unknown symbol __mulsf3
Unknown symbol __gesf2
Unknown symbol __addsf3

However, I don't know what those symbols are :( I am a bit worried that 
maybe I've done something that is not supported by the kernel, like 
left-shift 16 bits of an int, or floating operations.

Any hints?

Thanks a lot!
Lei

> 
> Cheers,
> Dick Johnson
> Penguin : Linux version 2.4.26 on an i686 machine (5570.56 BogoMips).
>             Note 96.31% of all statistics are fiction.
> 
> 

Re: Problems compiling kernel modules

[Richard B. Johnson]

On Mon, 23 Aug 2004, Lei Yang wrote:

> Richard B. Johnson wrote:
>
> > Do `depmod -e test.ko` to see what it's complaining about. You
> > can see all the symbols by using `nm`. Try it. Your code
> > probably didn't define the necessary stuff to make a module.
> > You need to look at a typical module (driver) that comes with the
> > kernel. Just find one of the shortest ".c" files in the driver
> > tree.
>
> Thanks! I did less /var/log/messages, and got the unknown symbols
> Unknown symbol __divsf3
> Unknown symbol __fixsfsi
> Unknown symbol __subsf3
> Unknown symbol __floatsisf
> Unknown symbol __mulsf3
> Unknown symbol __gesf2
> Unknown symbol __addsf3
>
> However, I don't know what those symbols are :( I am a bit worried that
> maybe I've done something that is not supported by the kernel, like
> left-shift 16 bits of an int, or floating operations.
>
> Any hints?
>
> Thanks a lot!
> Lei

You cannot use floating-point in the kernel. It appears that you
are trying to make user-mode code execute within the kernel. It
can't. That's not what a module does. The kernel executes code
on behalf of the user-mode caller, in the context of the caller.
It does things, on behalf of the user, that the user can't
be trusted to do properly by himself. That's all the kernel
is for! Any calculations and similar stuff can be done in
regular user-mode code.

Cheers,
Dick Johnson
Penguin : Linux version 2.4.26 on an i686 machine (5570.56 BogoMips).
            Note 96.31% of all statistics are fiction.

Re: Problems compiling kernel modules

[Alan Cox]

On Llu, 2004-08-23 at 15:39, Lei Yang wrote:
> Thanks! I did less /var/log/messages, and got the unknown symbols
> Unknown symbol __divsf3
> Unknown symbol __fixsfsi
> Unknown symbol __subsf3
> Unknown symbol __floatsisf
> Unknown symbol __mulsf3
> Unknown symbol __gesf2
> Unknown symbol __addsf3
> 
> However, I don't know what those symbols are :( I am a bit worried that 
> maybe I've done something that is not supported by the kernel, like 
> left-shift 16 bits of an int, or floating operations.

You are correct - the kernel doesn't support floating point operations
used in kernel space unless you do some fairly tricky stuff.

Re: Problems compiling kernel modules

[Lei Yang]

Richard B. Johnson wrote:
> On Mon, 23 Aug 2004, Lei Yang wrote:
> 
> 
>>Richard B. Johnson wrote:
>>
>>
>>>Do `depmod -e test.ko` to see what it's complaining about. You
>>>can see all the symbols by using `nm`. Try it. Your code
>>>probably didn't define the necessary stuff to make a module.
>>>You need to look at a typical module (driver) that comes with the
>>>kernel. Just find one of the shortest ".c" files in the driver
>>>tree.
>>
>>Thanks! I did less /var/log/messages, and got the unknown symbols
>>Unknown symbol __divsf3
>>Unknown symbol __fixsfsi
>>Unknown symbol __subsf3
>>Unknown symbol __floatsisf
>>Unknown symbol __mulsf3
>>Unknown symbol __gesf2
>>Unknown symbol __addsf3
>>
>>However, I don't know what those symbols are :( I am a bit worried that
>>maybe I've done something that is not supported by the kernel, like
>>left-shift 16 bits of an int, or floating operations.
>>
>>Any hints?
>>
>>Thanks a lot!
>>Lei
> 
> 
> You cannot use floating-point in the kernel. It appears that you
> are trying to make user-mode code execute within the kernel. It
> can't. That's not what a module does. The kernel executes code
> on behalf of the user-mode caller, in the context of the caller.
> It does things, on behalf of the user, that the user can't
> be trusted to do properly by himself. That's all the kernel
> is for! Any calculations and similar stuff can be done in
> regular user-mode code.

Sort of, I am trying to make a usr mode library work with kernel. 
However, floating point operation is necessary in the algorithm. You 
mean that this can never be done? Is changing floating-point the only 
thing I can do now?

Thanks!
Lei

> Cheers,
> Dick Johnson
> Penguin : Linux version 2.4.26 on an i686 machine (5570.56 BogoMips).
>             Note 96.31% of all statistics are fiction.
> 
> 

Re: Problems compiling kernel modules

[Richard B. Johnson]

On Mon, 23 Aug 2004, Lei Yang wrote:

> Richard B. Johnson wrote:
> > On Mon, 23 Aug 2004, Lei Yang wrote:
> >
> >
> >>Richard B. Johnson wrote:
> >>
> >>
> >>>Do `depmod -e test.ko` to see what it's complaining about. You
> >>>can see all the symbols by using `nm`. Try it. Your code
> >>>probably didn't define the necessary stuff to make a module.
> >>>You need to look at a typical module (driver) that comes with the
> >>>kernel. Just find one of the shortest ".c" files in the driver
> >>>tree.
> >>
> >>Thanks! I did less /var/log/messages, and got the unknown symbols
> >>Unknown symbol __divsf3
> >>Unknown symbol __fixsfsi
> >>Unknown symbol __subsf3
> >>Unknown symbol __floatsisf
> >>Unknown symbol __mulsf3
> >>Unknown symbol __gesf2
> >>Unknown symbol __addsf3
> >>
> >>However, I don't know what those symbols are :( I am a bit worried that
> >>maybe I've done something that is not supported by the kernel, like
> >>left-shift 16 bits of an int, or floating operations.
> >>
> >>Any hints?
> >>
> >>Thanks a lot!
> >>Lei
> >
> >
> > You cannot use floating-point in the kernel. It appears that you
> > are trying to make user-mode code execute within the kernel. It
> > can't. That's not what a module does. The kernel executes code
> > on behalf of the user-mode caller, in the context of the caller.
> > It does things, on behalf of the user, that the user can't
> > be trusted to do properly by himself. That's all the kernel
> > is for! Any calculations and similar stuff can be done in
> > regular user-mode code.
>
> Sort of, I am trying to make a usr mode library work with kernel.
> However, floating point operation is necessary in the algorithm. You
> mean that this can never be done? Is changing floating-point the only
> thing I can do now?
>
> Thanks!
> Lei

Let's put it this way. If you think you need to use a floating-point
library inside the kernel, then you don't understand what the kernel
does or what it was designed to do. You should make a module that
reads from, or writes to, the special hardware you are using. Then,
using user mode code (called a daemon), you read from the device,
perform the floating-point processing, then write to the device.
That way, you are using the kernel priviliges only for reading/writing
to the device.

It is possible to execute floating point code within the kernel
if the context of the floating-point unit is saved first, and
restored after the operation. However, you will never get a
math library to work inside the kernel unless you write your
own. You cannot use the 'C' runtime library inside the kernel.
That library was designed to be outside the kernel (it uses
the kernel).


> > Cheers,
> > Dick Johnson
> > Penguin : Linux version 2.4.26 on an i686 machine (5570.56 BogoMips).
> >             Note 96.31% of all statistics are fiction.
> >
> >
>

Cheers,
Dick Johnson
Penguin : Linux version 2.4.26 on an i686 machine (5570.56 BogoMips).
            Note 96.31% of all statistics are fiction.

Re: Problems compiling kernel modules

[Sam Ravnborg]

On Mon, Aug 23, 2004 at 11:04:28AM -0400, Lei Yang wrote:
> 
> Sort of, I am trying to make a usr mode library work with kernel. 
> However, floating point operation is necessary in the algorithm. You 
> mean that this can never be done? Is changing floating-point the only 
> thing I can do now?

Before helping out more with your compile issue please explain in propser
detail what you try to achive.
Reading the above I get the impression you thing a library will run
faster when running in kernel context - and thats what you try to do.

If this is your plan then the answer is: Drop it.

	Sam

Re: Problems compiling kernel modules

[Lei Yang]

Sam Ravnborg wrote:
> On Mon, Aug 23, 2004 at 11:04:28AM -0400, Lei Yang wrote:
> 
>>Sort of, I am trying to make a usr mode library work with kernel. 
>>However, floating point operation is necessary in the algorithm. You 
>>mean that this can never be done? Is changing floating-point the only 
>>thing I can do now?
> 
> 
> Before helping out more with your compile issue please explain in propser
> detail what you try to achive.
> Reading the above I get the impression you thing a library will run
> faster when running in kernel context - and thats what you try to do.
> 
> If this is your plan then the answer is: Drop it.


NO, this is not my plan :)

I was trying to build a compression/decompression utility with my 
algorithm in kernel, and want to use it in some of the device drivers.
And in that algorithm, we need floating-point.

Thanks!
Lei

Re: Problems compiling kernel modules

[Andreas Schwab]

"Richard B. Johnson" <root@chaos.analogic.com> writes:

> A function looks like this:
>
> int present()
> {
>
> }
>
> A prototype for the same function looks like this:
>
> int present(void);
>
> Functions always have "{}". Prototypes never do.

A function definition is also a prototype unless you use oldstyle
definitions.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Problems compiling kernel modules

[Alan Cox]

On Llu, 2004-08-23 at 16:44, Lei Yang wrote:
> I was trying to build a compression/decompression utility with my 
> algorithm in kernel, and want to use it in some of the device drivers.
> And in that algorithm, we need floating-point.

In which case the best place to look (if it needs to be kernel side) is
probably drivers/md/ which shows how you can use the FPU state. There is
a cost to it as you have to save/restore the user FP state and on x86
that is expensive of course.

Historically we've always tried to keep compression algorithms in user
space. The video4linux layer for example pushes most of this to the user
and that allows the user program to make a more intelligent assessment
of the input format and desired target. This avoids things like kernel
drivers turning data from one format to another and user space libraries
turning it back again.

Alan