Can anyone please help me with getting the proper header files needed for the copy_from_user method?
I found a few of the include headers I need, but my compiler keeps saying that they are not found. I am running CentOS on my machine. I have tried yum installing various kernel-headers and devel packages but still no luck.
Is there a special segment I need to add in my gcc command? Everything I find on the Internet only tells me how to use the method but not actually how I can get access to it in the first place.
I assume you're developing a kernel module, because outside of it trying to use copy_from_user wouldn't make sense. Either way, in the kernel use:
#include <linux/uaccess.h>
Edit: if building a kernel module is what you want, you may want to look at this Hello World Linux Kernel Module. Specifically the makefile portion may be of interest to you (search for obj-m).
Related
I asked a question and got a sketch of how to open and patch a Fedora package. See How to modify a Fedora package and fix bugs
What was missing was how to work on the package. I cannot build it outside of the chroot, apparently because of a problem with Qt (The package uses Qt3). I need to know how to get into the details of makes and tests because I want software that is actually part of the SRPM, but does not make it into the distributed RPM -- it is only used to test the package during building.
So how do I find the chroot, get into it, mess around, and build some of the messed-around bits, fix what I just broke and try again, and maybe use the final result outside the chroot? Or maybe there's a completely different way.
None of the docs I've seen get into these dirty little bits. And it is complicated by my inability to do a build outside the chroot.
In the end, I'll probably construct an SRPM (for my own use) that just makes the test program (a command-line version of the graphic program that the original package is all about). But I'll need to work on it quite a bit before that's ready to go.
Probably it's good enough if someone can show me how and where to get into the chroot and do commands like 'make', then use the results outside the chroot.
I am trying to use some open-source CFD code, and it uses PETSC and some other libraries, so I installed them. But when I try to compile program useing 'make', it seems like libraries are not properly linked with makefile
It seems like petsc isn't properly linked, but I can't know why...
The problem is that PETSc depends on some more libraries (X11) than the CFD package counted on. It should have a proper configure that figures these out. However, you can get the link line you need using
cd PETSC_DIR; make getlinklibs
which you can then put in LIBFLAG.
I'm afraid my question is a bit complex. Appreciate anyone who can help.
Some background:
I have a 3rd party SW package that compile both kernel modules and user space applications.
Unfortunately, this 3rd party is very complex, and doesn't use Kbuild for building kernel modules (I tried without success)
When compiling the kernel modules, I add -I{path to kernel headers}, but I see the .config file is not being parsed in the compilation, which, of course, causes many errors.
I tried to manually add all flags from .config to gcc in command line (using a script to generate the command line) but that was a very very long line and gcc couldn't handle it.
So my question would be: Is there a way to force all these flags to gcc somehow?
Appreciate your ideas :)
Clarification:
The 3rd party SW can compile on older kernels (2.6, 2.4) I'm trying to compile it for 3.2
Maybe if someone can explain how the original kernel Makefile manages the .config file, I can mimic that behavior.
After digging in the kernel sources, I found the answer. Here it is in case someone needs it.
There's an automatically generated h file called autoconf.h which contains all the relevant definitions in C pre processor format. Just need to include it manually when compiling the module.
Also in theory, I could use my script to create such a file and include it from the sources.
Hope this helps someone. Now on to the next problem :)
I'm new in writing Linux device driver, and I'm wondering how the kernel Makefile magically knows what to compile. To illustrate what I don't understand, consider the following case:
I did a #include <linux/irq.h> in my driver code and I'm able to find the header file irq.h in the kernel directory KDIR/include/linux. However, this is only the header file, so I thought the irq.c source code must be out there somewhere. Hence, I looked into the KDIR/arch/arm searching for irq.c (since I'm using the ARM architecture). My confusion begins here when I found really many irq.c inside KDIR/arch/arm. To simply list a few, I got:
KDIR/arch/arm/mach-at91/irq.c
KDIR/arch/arm/mach-davinci/irq.c
KDIR/arch/arm/mach-omap1/irq.c
KDIR/arch/arm/mach-orion5x/irq.c
many more...
In my Makefile, I have a line like this:
$(MAKE) -C $(KDIR) M=$(PWD) CROSS_COMPILE=arm-none-linux-gnueabi- ARCH=arm modules
So I understand that the kernel Makefile knows that I'm using the ARM architecture, but under KDIR/arch/arm/, there are so many irq.c with the same name. I'm guessing that the mach-davinci/irq.c is compiled since davinci is the cpu name I'm using. But then, how can the kernel Makefile knows this is the one to compile? Or if I would like to have a look for the irq.c that I'm actually using, which one should I refer to?
I believe there must be a way to know this besides reading the long kernel Makefile. Thanks for any help!
Beyond the ARCH variable, you can also choose the system type (mach) from the configuration menu (there is actually a sub-menu called "System type" when you type make menuconfig for instance). This selection will include and compile all files under linux2.6/arch/$ARCH/mach-$MACH, and in your case this is how only one irq.c gets compiled.
That aside, it is interesting to understand how the kernel chooses which files to compile. The mechanism behind this is called Kconfig, and it is what allows you to precisely configure your kernel using make menuconfig and others, to compile a module from the outside like you are doing, and to select the right files to compile from simple Makefiles. While it is simple to use, its internals are rather complex - but this article, although rather old, explains it rather well:
http://www.linuxjournal.com/article/6568
To make a very long story short, there's a target make config, which you can trace. That one generates .config, that is your main guideline to making dependencies and controlling what will be compiled, what not, what as module and what will be compiled into the kernel.
This guide should give you a basic understanding of building a kernel module (and I assume that's where you want to start with your driver).
This is the FindGTK.cmake:
# don't even bother under WIN32
IF(UNIX)
...
ENDIF(UNIX)
So it's not intended to work in windows at all,even though I've already installed the gtk+-bundle_2.20.0-20100406_win32 days ago.
How should I properly use gtk with cmake now?
Given that you are using GTK 2.20.0 (i.e. version is >= 2), you should be using GTK2 instead of GTK. But, if FindGTK2 has the same problem, then you can use find_path to locate the header files, and you can use find_library to locate the associated library files. Putting those together, you can construct the symbols GTK2_FOUND, GTK2_LIBRARIES, and GTK2_INCLUDE_DIRS that it should produce. You may find my FindUnitTestPlusPlus.cmake file a little bit helpful; it makes use of "FindPackageHandleStandardArgs", which takes care of the nitty gritty details of making sure to fail if the library isn't there and the REQUIRED flag is given. Unfortunately, there really isn't much documentation out there on creating custom FindXYZ.cmake modules; however, you should be able to hack something together from the existing modules, I think.
Another option is to contact the maintainer of that particular module. A list of CMake find module maintainers may be found at the link. Philip Lowman is the go-to guy for the FindGTK2 module.