Re: status of u32 type in 2.6.29.4 ?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



why not use KDB which has merged into linux kernel?


BRs

Lin

2009/8/6 Microbit_Ubuntu <microbit@xxxxxxxxxxxxxxxxxxxxxx>:
> Hi Lin !
>
> On Tue, 2009-08-04 at 21:54 +0800, Pei Lin wrote:
>> Do u notice the macro " #ifdef  __KERNEL__ " in these headers?
>> u compile the kernel it will declare this macro.
>> give a web link i think maybe it can give u some help.
>> http://www.linuxforums.org/forum/linux-programming-scripting/54130-inclusion-kernel-header-files.html
>>
>> BRs
>> Lin
>>
>> 2009/8/1 Microbit_Ubuntu <microbit@xxxxxxxxxxxxxxxxxxxxxx>:
>> > On Fri, 2009-07-31 at 08:53 +1000, Microbit_Ubuntu wrote:
>> >> Hi all,
>> >>
>> >> I'm a bit confused as to the status of the type 'u32' in the kernel I
>> >> use (2.6.29.4).
>> >> u32 is used in thread_info.h, but types.h uses __u32.
>> >>
>> >> Now, while googling I came across a recent patch -
>> >> {Mon Feb 09 2009 Chuck Ebbert <cebbert@xxxxxxxxxx> +- Fix type in header
>> >> so iptables will build. (#484679) }
>> >> Although not related, it's the same issue - the patch applies a change
>> >> from u32 to __u32.
>> >>
>> >> Should I change the type u32 -> __u32 in thread_info.h  ???
>> >> I'm not comfortable with that because that's "stable" kernel source.
>> >>
>> >> Or am I simply overlooking some runtime constant/defintion I should have
>> >> present...
>> >> I can't see why that would be, I've built various modules before, never
>> >> had an issue like this.. ?
>> >>
>> >>
>> >> For reference, this is the chain (module.h -> downwards) - that causes
>> >> the error :
>> >>
>> >> In file included
>> >> from /home/kris/buildroot-2009.05/toolchain_build_arm_nofpu/linux-2.6.29.4/include/linux/preempt.h:9,              from /home/kris/buildroot-2009.05/toolchain_build_arm_nofpu/linux-2.6.29.4/include/linux/spinlock.h:50,                 from /home/kris/buildroot-2009.05/toolchain_build_arm_nofpu/linux-2.6.29.4/include/linux/mmzone.h:7,                 from /home/kris/buildroot-2009.05/toolchain_build_arm_nofpu/linux-2.6.29.4/include/linux/gfp.h:4,                 from /home/kris/buildroot-2009.05/toolchain_build_arm_nofpu/linux-2.6.29.4/include/linux/kmod.h:22,                 from /home/kris/buildroot-2009.05/toolchain_build_arm_nofpu/linux-2.6.29.4/include/linux/module.h:13,                   from ../my_foo.c:11:
>> >> /home/kris/buildroot-2009.05/toolchain_build_arm_nofpu/linux-2.6.29.4/include/linux/thread_info.h:26: error: expected specifier-qualifier-list before 'u32'
>> >> /home/kris/buildroot-2009.05/toolchain_build_arm_nofpu/linux-2.6.29.4/include/linux/thread_info.h:39: error: expected specifier-qualifier-list before 'u64'
>> >>
>> >
>> >
>> > Hm, perhaps I should have clarified that this module compiles fine using
>> > the standard Make approach.  (eg. make M=path_to_workspace).
>> > I'm a bit at a loss why the u32 datatype isn't a problem when using the
>> > module make... :
>> > It's when I use Eclipse CDT (Galileo), that the indexer screws up and
>> > content lost fails, together with compilation error.
>> > While Googling I've come across threads about bug in Eclipse CDT.
>> > I'm still trying to resolve this.
>> >
>> > I realise this isn't an Eclipse group, but at first I thought the
>> > problem was in my kernel setup, it isn't.
>> > Anyone here who found an elegant solution to this CDT problem ? (You
>> > never know). I don't really know yet if/how the procedure is to debug
>> > with remote GDB (from within Eclipse) for modules.
>> >
>> > I presume Galileo can be tamed to handle Kernel modules.... (?)
>> > Compiling and debugging from the IDE for "normal" userspace code works
>> > fine with dynamic or static linked libraries.
>> >
>> > I'm trying to get this going because it's possible to learn the kernel
>> > that much faster again, Galileo's content index brings up all relevant
>> > structs, macros etc etc. in 1-2-3...
>> >
>> > I'm using GCC 4.3.2 on ARM9 cross-target btw.
>> >
>> > Thanks in advance for any possible insight or tips !
>> >
>> > --
>> > Best regards,
>> > Kris
>> >
>
>
> I was sidetracked with other issues, but I resolved this issue in the
> interim.
> You're quite right, that was the common denominator (__KERNEL__), but
> the exact problem ended up being a LOT more tricky than that.
> Hours of googling didn't help, as there's nothing around specific to
> cross-compiling. (not that I could find)
>
> The solution was that the Eclipse environment itself really goes to lala
> land about finding executables for module building.
> I constantly struggled with Make [2] Error 127....
>
> Despite very clear Environment definitions and path definitions, Eclipse
> wanted absolute paths in the Makefile and over-verbose Target and Cross
> Compile declarations.
>
> A sample/excerpt of my Makefile in case anyone runs into this mess
> themselves :
>
>
> PWD       := $(shell pwd)
>
> SAM9_BUILDROOT     = /home/kris/buildroot-2009.05
> PROJECT_BUILD_ARM  = $(wildcard $(SAM9_BUILDROOT)/project_build_arm)
> BUILD_ARM          = $(wildcard $(SAM9_BUILDROOT)/build_arm)
> CROSS_KERNELDIR    = $(PROJECT_BUILD_ARM)/SAM9/linux-2.6.29.4
> CROSS_COMPILE      = $(BUILD_ARM)/staging_dir/usr/bin/arm-linux-
>
> all: kernel-module
> .PHONY: kernel-module
>
> TARGET_ARCH=-Os -march=armv5te -mtune=arm9tdmi -Wa,-mcpu=arm
> CC = $(CROSS_COMPILE)gcc
>
> kernel-module:
>  $(MAKE) -C $(CROSS_KERNELDIR) M=$(PWD) ARCH=arm CROSS_COMPILE=
> $(CROSS_COMPILE) modules
>
>
>
> I hope this helps someone else one day. I lost about a day and a half
> with this issue, but perseverance gets you there :-)
>
>
> My next hurdle now is to figure how to debug using GDB on Kernel
> Modules. Does anyone have any insight on this ?
> I can't just start debug on the module, because it hasn't been inserted.
> I can't just start insmod on the target either, because then the
> debugger isn't executing the "test" module.
>
> I might send a separate post on that to see if anyone has done this
> before.
>
>
> --
> Best regards,
> Kris
>
>
>
> --
> To unsubscribe from this list: send an email with
> "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
> Please read the FAQ at http://kernelnewbies.org/FAQ
>
>

--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ



[Index of Archives]     [Newbies FAQ]     [Linux Kernel Mentors]     [Linux Kernel Development]     [IETF Annouce]     [Git]     [Networking]     [Security]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux SCSI]     [Linux ACPI]
  Powered by Linux