how about KBUILD_MODNAME

how about KBUILD_MODNAME

[hacklu]

I don't understand the macro KBUILD_MODNAME .
when I compile a  driver program. It returns me "linux/pci.h:655: error: 'KBUILD_MODNAME' undeclared (first use in this function) "

In the makefile I had used the "-D" options




thanks a lot

2010-08-03 



hacklu 

Re: how about KBUILD_MODNAME

[Américo Wang]

On Tue, Aug 03, 2010 at 03:11:59PM +0800, hacklu wrote:
>
>I don't understand the macro KBUILD_MODNAME .
>when I compile a  driver program. It returns me "linux/pci.h:655: error: 'KBUILD_MODNAME' undeclared (first use in this function) "
>
>In the makefile I had used the "-D" options
>

You don't need to care about KBUILD_MODNAME, it is defined
internally by kbuild and passed to your module via "-DKBUILD_MODNAME=XXX"
automatically.

So, it looks like you didn't write your makefile correctly.

Re: Re: how about KBUILD_MODNAME

[hacklu]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="gb2312", Size: 1398 bytes --]


I am compiling the boardcom's driver now.
the driver had defined EXTRA_CFLAGS = -D"KBUILD_STR(s)=\#s" $(basename_flags) $(modname_flags) 
in the a.makefile.
and the a.makefile was included by b.makefile.
when in the b.makefile,
there is this command.
 $(CC) $(DEPS_OPT) $(CFLAGS) $(EXTRA_CFLAGS) -o $@ -c $< ;) 

I had add "echo $(EXTRA_CFLAGS)" before this line;but returns NULL;

so I suspicion the $(EXTRA_CFLAGS) hasn't been work.

I aslo try to add "export EXTRA_CFLAGS" in a.makefile,but it doesn't work either.

the problem has puzzled me for some days.

help me please~~



2010-08-03 



hacklu 



·¢¼þÈË£º Am¨¦rico Wang 
·¢ËÍʱ¼ä£º 2010-08-03  16:32:08 
ÊÕ¼þÈË£º hacklu 
³­ËÍ£º linux-kernel 
Ö÷Ì⣺ Re: how about KBUILD_MODNAME 
 
On Tue, Aug 03, 2010 at 03:11:59PM +0800, hacklu wrote:
>
>I don't understand the macro KBUILD_MODNAME .
>when I compile a  driver program. It returns me "linux/pci.h:655: error: 'KBUILD_MODNAME' undeclared (first use in this function) "
>
>In the makefile I had used the "-D" options
>
You don't need to care about KBUILD_MODNAME, it is defined
internally by kbuild and passed to your module via "-DKBUILD_MODNAME=XXX"
automatically.
So, it looks like you didn't write your makefile correctly.
ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥

Re: how about KBUILD_MODNAME

[Boaz Harrosh]

On 08/03/2010 10:11 AM, hacklu wrote:
> 
> I don't understand the macro KBUILD_MODNAME .
> when I compile a  driver program. It returns me "linux/pci.h:655: error: 'KBUILD_MODNAME' undeclared (first use in this function) "
> 
> In the makefile I had used the "-D" options
> 
> thanks a lot
> 
> 2010-08-03 
> 
> hacklu 
> 

The KBUILD_MODNAME fails to be set when there are two drivers built from the same
directory. There are many directories in the source tree with more then one driver
but they don't use the pr_debug macro.

Cheers
Boaz

Re: how about KBUILD_MODNAME

[Boaz Harrosh]

On 08/03/2010 12:52 PM, Boaz Harrosh wrote:
> On 08/03/2010 10:11 AM, hacklu wrote:
>>
>> I don't understand the macro KBUILD_MODNAME .
>> when I compile a  driver program. It returns me "linux/pci.h:655: error: 'KBUILD_MODNAME' undeclared (first use in this function) "
>>
>> In the makefile I had used the "-D" options
>>
>> thanks a lot
>>
>> 2010-08-03 
>>
>> hacklu 
>>
> 
> The KBUILD_MODNAME fails to be set when there are two drivers built from the same
> directory. There are many directories in the source tree with more then one driver
> but they don't use the pr_debug macro.
> 
> Cheers
> Boaz

Rrr it was a long time since I fought this. Maybe it's not the problem with two
drivers in same dir, maybe it's when two drivers share the same foo.c file.

Boaz

Re: Re: how about KBUILD_MODNAME

[Sam Ravnborg]

On Tue, Aug 03, 2010 at 05:35:40PM +0800, hacklu wrote:
> 
> I am compiling the boardcom's driver now.
> the driver had defined EXTRA_CFLAGS = -D"KBUILD_STR(s)=\#s" $(basename_flags) $(modname_flags) 
> in the a.makefile.
> and the a.makefile was included by b.makefile.
> when in the b.makefile,
> there is this command.
>  $(CC) $(DEPS_OPT) $(CFLAGS) $(EXTRA_CFLAGS) -o $@ -c $< ;) 
> 
> I had add "echo $(EXTRA_CFLAGS)" before this line;but returns NULL;
> 
> so I suspicion the $(EXTRA_CFLAGS) hasn't been work.
> 
> I aslo try to add "export EXTRA_CFLAGS" in a.makefile,but it doesn't work either.
> 
> the problem has puzzled me for some days.
> 
> help me please~~


It looks like the driver uses the old 2.4 way to define a Makefile.
This will not work with 2.6.

What you need to do is to define a Makefile (*) like you would
if the driver was included in the kernel and then build
it using the following command:

make -C path/to/kernel/ M=`pwd`

The kernel shall be built before you do this as the method uses
information from the buitl kernel.

(*) The Makefile may not refer to new CONFIG_ symbols.
So it likely looks like this:

obj-m := foo.o bar.o

Do not be suprised that the Makefile becomes much much simpler - this is expected.

	Sam

Re: Re: how about KBUILD_MODNAME

[Américo Wang]

On Tue, Aug 03, 2010 at 05:35:40PM +0800, hacklu wrote:
>
>I am compiling the boardcom's driver now.
>the driver had defined EXTRA_CFLAGS = -D"KBUILD_STR(s)=\#s" $(basename_flags) $(modname_flags) 
>in the a.makefile.
>and the a.makefile was included by b.makefile.
>when in the b.makefile,
>there is this command.
> $(CC) $(DEPS_OPT) $(CFLAGS) $(EXTRA_CFLAGS) -o $@ -c $< ;) 
>
>I had add "echo $(EXTRA_CFLAGS)" before this line;but returns NULL;
>
>so I suspicion the $(EXTRA_CFLAGS) hasn't been work.
>


You don't need to write this line by yourself, you just
need to provide a correct: obj-$(XXXXX) += your_module.o,
kbuild will automatically compile it with proper flags.
(If not, try CFLAGS_MODULE.)

If you insist to do this, I think you can just append
-D"KBUILD_MODNAME=your_module" to that line by hand.

Hope this helps.

Re: how about KBUILD_MODNAME

[Américo Wang]

On Tue, Aug 03, 2010 at 12:56:59PM +0300, Boaz Harrosh wrote:
>On 08/03/2010 12:52 PM, Boaz Harrosh wrote:
>> On 08/03/2010 10:11 AM, hacklu wrote:
>>>
>>> I don't understand the macro KBUILD_MODNAME .
>>> when I compile a  driver program. It returns me "linux/pci.h:655: error: 'KBUILD_MODNAME' undeclared (first use in this function) "
>>>
>>> In the makefile I had used the "-D" options
>>>
>>> thanks a lot
>>>
>>> 2010-08-03 
>>>
>>> hacklu 
>>>
>> 
>> The KBUILD_MODNAME fails to be set when there are two drivers built from the same
>> directory. There are many directories in the source tree with more then one driver
>> but they don't use the pr_debug macro.
>> 
>> Cheers
>> Boaz
>
>Rrr it was a long time since I fought this. Maybe it's not the problem with two
>drivers in same dir, maybe it's when two drivers share the same foo.c file.
>

No, it is not, you can find many drivers under drivers/net/. ;)

And it doesn't make sense to hold two drivers in one .c file.

Re: how about KBUILD_MODNAME

[Boaz Harrosh]

On 08/03/2010 01:15 PM, Américo Wang wrote:
> 
> And it doesn't make sense to hold two drivers in one .c file.
> 

I meant when two drivers share the same .c file. But instead of
using a third common module they just share it by duplicating
the code. example:

<Kbuild>
drv1-y := drv-one.o common.o
obj-$(CONFIG_DRV1) += drv1.o

drv2-y := drv-two.o common.o
obj-$(CONFIG_DRV2) += drv2.o
</Kbuild>

When compiling common.o the KBUILD_MODNAME fails to be set

Cheers
Boaz

Re: how about KBUILD_MODNAME

[Sam Ravnborg]

On Tue, Aug 03, 2010 at 01:24:41PM +0300, Boaz Harrosh wrote:
> On 08/03/2010 01:15 PM, Américo Wang wrote:
> > 
> > And it doesn't make sense to hold two drivers in one .c file.
> > 
> 
> I meant when two drivers share the same .c file. But instead of
> using a third common module they just share it by duplicating
> the code. example:
> 
> <Kbuild>
> drv1-y := drv-one.o common.o
> obj-$(CONFIG_DRV1) += drv1.o
> 
> drv2-y := drv-two.o common.o
> obj-$(CONFIG_DRV2) += drv2.o
> </Kbuild>
> 
> When compiling common.o the KBUILD_MODNAME fails to be set

Correct - but I do not think this is relavent in this case.
The code snippet shown clearly indicates that the drivers
uses a 2.4 style Makefile. This will not work with 2.6.

	Sam