I'm working on a new system call for the kernel linux 2.6.32, with the aim to do a myOpen very close to the original open.
I've modified the original struct file (linux/fs.h) with a new variable and i want to continue to use the original fileTable also with myOpen (I hope to add myOpen in the code of the original open, switching in my case with a simply flag).
To do this I compile my code in a module (module.ko) and load this dinamically on my kernel (the one with the fs.h modified).
Now the problem is that if I use some function relative to the file system (ex: get_unused_fd_flags(flags); fd_install(fd, f); etc etc), some variable are not found (i recive it like warning and also in the kernel terminal).
I think the problem is that I Try to use some kernel function, but I do the same with others like filp_open and I not recive error. How I can solve this?
Terminal:
make -C /lib/modules/2.6.32progb/build M=/home/mauro/Scrivania modules
make[1]: ingresso nella directory "/home/mauro/Scrivania/linux-2.6.32.B"
Building modules, stage 2.
MODPOST 1 modules
WARNING: "alloc_fd" [/home/mauro/Scrivania/moduloB.ko] undefined!
make[1]: uscita dalla directory "/home/mauro/Scrivania/linux-2.6.32.B"
[sudo] password for mauro: insmod: error inserting 'moduloB.ko': -1 Unknown symbol in module
alloc_fd is not exported to modules.
This is a hint by the kernel developers that they don't want to encourage module developers to call the function. Now, since the kernel is open-source, you can of course export the function anyway by simply modifying the kernel source to add: "EXPORT_SYMBOL(alloc_fd);" just after the function in fs/file.c
Some functions you're trying to use are already exported - hence you don't get a warning for them.
Related
I'm trying to automatically label my application sign-on line with a build number. This application is a plain vanilla C one without graphic UI; it is intended for command line, therefore it is a "simple" one.
The sign-on id is located in a "template" source file which is customized by CMake with a configure_file() command. Recently, I fancied to include a build number in this sign-on id. Consequently, the customization can no longer be statically done at CMake time, but everytime make is invoked.
To achieve that, there are two possibilities in CMake:
add_custom_target(), but it is triggered even when nothing else changes in the source tree which does not reflect the state of the tree;
add_custom_command(), which can be triggered only when the application (target) needs to be linked again.
I opted for the second solution and did not succeed.
Here is an extract of my CMakeLists.txt, the sign-on id being in file ErrAux.c (template in PROJECT_SOURCE_DIR, configured in PROJECT_BINARY_DIR):
add_executable(anathem ... ${PROJECT_BINARY_DIR}/ErrAux.c ...)
add_custom_command(TARGET anathem PRE_LINK
COMMAND "${CMAKE_COMMAND}" "-DVERS=${PROJECT_VERSION}"
"-DSRC=${PROJECT_SOURCE_DIR}"
"-DDST=${PROJECT_BINARY_DIR}"
-P "${CMAKE_HOME_DIRECTORY}/BuildNumber.cmake"
WORKING_DIRECTORY "${CMAKE_CURRENT_SOURCE_DIR}"
COMMENT "Numbering build"
VERBATIM
)
This launches script BuildNumber.cmake just before the link step. It computes the next build number and customizes ErrAux.c with configure_file().
It works fine, except ...
It happens late in the make sequence and the update to ErrAux.c goes unnoticed. The sign-on id in the executable contains the previous build number.
Next time I run make, make notices the generated ErrAux.c is younger than its object module and causes it to be compiled again, which in turn causes a link which triggers a build number update. This happens even if no other file has changed and this loop can't be broken. This is clearly shown in the compiling log:
Scanning dependencies of target anathem
[ 13%] Building C object AnaThem/CMakeFiles/anathem.dir/ErrAux.c.o
[ 14%] Linking C executable anathem
Numbering build
3.0.0-45
[ 36%] Built target anathem
The crux seems to be that add_custom_command(TARGET ...) can't specify an output file like add_custom_command(OUTPUT ...) does. But this latter form can't be triggered in PRE_LINK mode.
As a workaround, I forced a compilation to "refresh" the object module with:
add_custom_command(TARGET anathem PRE_LINK
COMMAND "${CMAKE_COMMAND}" "-DVERS=${PROJECT_VERSION}"
"-DSRC=${PROJECT_SOURCE_DIR}"
"-DDST=${PROJECT_BINARY_DIR}"
-P "${CMAKE_HOME_DIRECTORY}/BuildNumber.cmake"
COMMAND echo "Numbering"
COMMAND echo "${CMAKE_C_COMPILER}" "\$(C_DEFINES)" "\$(C_INCLUDES)" "\$(C_FLAGS)" -c "${PROJECT_BINARY_DIR}/ErrAux.c"
COMMAND "${CMAKE_C_COMPILER}" "\$(C_DEFINES)" "\$(C_INCLUDES)" "\$(C_FLAGS)" -c "${PROJECT_BINARY_DIR}/ErrAux.c"
WORKING_DIRECTORY "${CMAKE_CURRENT_SOURCE_DIR}"
COMMENT "Numbering build"
VERBATIM
)
An explicit compilation is forced after sign-on id customization. It mimics what is found in the various Makefile's and my not be safe for production. It's a cheat trick on both CMake and make.
UPDATE: Option -c is required to postpone link step until the final application liniking process.
This addition creates havoc in the link, as shown by the log, where you see a double compilation (the standard make one and the add_custom_command() one):
Scanning dependencies of target anathem
[ 13%] Building C object AnaThem/CMakeFiles/anathem.dir/ErrAux.c.o
[ 14%] Linking C executable anathem
Numbering build
3.0.0-47
Numbering
/usr/bin/cc -DANA_DEBUG=1 -I/home/prog/projects/AnaLLysis/build/AnaThem -I/home/prog/projects/AnaLLysis/AnaThem -g /home/prog/projects/AnaLLysis/build/AnaThem/ErrAux.c
/usr/lib/gcc/x86_64-redhat-linux/6.3.1/../../../../lib64/crt1.o: In function `_start':
(.text+0x20): undefined reference to `main'
collect2: error: ld returned 1 exit status
AnaThem/CMakeFiles/anathem.dir/build.make:798: recipe for target 'AnaThem/anathem' failed
make[2]: *** [AnaThem/anathem] Error 1
If I force a full recompilation, to make sure all sources are compiled, *main.c* included, I get the same error on `main`.
The only logical explanation is my manual C invocation is faulty and somehow destroys vital information. I checked with *readelf* that `main` is still in the symbol table for *main.c.o* and that it is still taken into account by the link step (from file *link.txt*).
UPDATE: Even with the correct link, I'm still experiencing the infinite loop syndrom. The generated application still has its sign-on id lagging behind the actual build counter.
Can someone give me a clue for the right direction?
FYI I'm quite new to CMake, so I may do things really wrong. Don't hesitate to criticize my mistakes.
The key to the solution is to put the generated module where make expects to find it. CMake organizes the build tree in a non-trivial way.
The shortcomming in my added compilation in add_custom_command() was to believe that by default the binary will be stored in the "usual" CMake locations. Since I forge manually my compiler command, this is not the case.
I found the module in the source directory, which is a consequence of the WORKING_DIRECTORY option, with name ErrAux.o and not ErrAux.c.o.
To obtain the correct behavior, I force an output location with:
-o "${PROJECT_BINARY_DIR}/CMakeFiles/anathem.dir/ErrAux.c.o"
Now, when I run make again, nothing happens since nothing changed.
Side question
To make the solution portable (if needed), are there CMake variables for CMakeFiles and anathem.dir directories? Or in the latter case, for the current target as "anathem" as the target name in add_custom_command()?
I am trying to cross compile a simple program with the arm toolchain. And stdio library points to another library, which results in the following error:
/home/sansari/tools/arm-eabi-4.7/bin/arm-eabi-gcc hello.c -o hello
In file included from hello.c:3:0:
/home/sansari/tools/arm-eabi-4.7/bin/../lib/gcc/arm-eabi/4.7/include-fixed/stdio.h:50:23: fatal error: sys/cdefs.h: No such file or directory
compilation terminated.
make: *** [hello] Error 1
At first, I thought this file is in some subdirectory of the toolchain, and I need to include the folder for this library in my makefile. But a quick tree output says that it is not. So given that I have used this toolchain successfully for a larger project, I know it is copied from somewhere. So my question is how do I add it to this project please? And what is the appropriate place to copy it from? I am trying to understand why it is not in the toolchain folders that I have, and how I should add it to my project please.
#Olaf - You have been very helpful; I however have a little more learning curve. But I do understand what you are instructing. I know I have the libraries in my build system since have built for this platform successfully. I even know that it is in my WORKING_DIRECTORY. What I do not know is if I can copy a folder and address the issue entirely or do I need to keep compiling and see what errors I get. That is do it incrementally. For example, one of the files, which was missing was cdefs.h. And I was able to find it in the folder:
/home/sansari/ndk/android-ndk-r10d/platforms/android-19/arch-arm/usr/include/sys/cdefs_elf.h
So I copied it over and the build process proceeded to the next stage. I do like to know if I should perhaps have copied the entire /sys or /include directory or compared the /include directory of my source and make sure all the files are also in the destination directory also. And that way I can avoid having to compile a number of times.
But nevertheless, I proceeded with copying one file at a time. The last error I got is:
/home/sansari/tbt/tools/arm-eabi-4.7/bin/../lib/gcc/arm-eabi/4.7/include/stdint.h:3:26: fatal error: stdint.h: No such file or directory
And I look in the include directory; I see a file call stdint.h
What do you make of that? Does that make sense to you? I am confused by this error. How can I get this error when the file is in the directory. Basically it seems make is saying this file does not exist when it does.
I did find This post also, which seems to say what you are saying. I just need to know what is the best way to address it.
#Olaf - I really appreciate all your help. I was able to get through all the library errors by putting an include statement in my makefile. Now the linker is giving me errors as follows:
/home/sansari/tbt/tools/arm-eabi-4.7/bin/arm-eabi-gcc -I../../ndk/android-ndk-r10d/platforms/android-19/arch-arm/usr/include hello.c -o hello
/home/sansari/tbt/tools/arm-eabi-4.7/bin/../lib/gcc/arm-eabi/4.7/../../../../arm-eabi/bin/ld: cannot find crt0.o: No such file or directory
/home/sansari/tbt/tools/arm-eabi-4.7/bin/../lib/gcc/arm-eabi/4.7/../../../../arm-eabi/bin/ld: cannot find -lc
collect2: error: ld returned 1 exit status
make: *** [hello] Error 1
update - I searched for a solution for the above errors. The first error is discussed here and -nostartfiles switch seems to work for me for now. I found this link that talks about libc.a being the fix for the error about not finding -lc. So I found an appropriate copy of libc.a and passed the location to the linker. The program compiles, but I get one last warning as follows:
warning: cannot find entry symbol _start; defaulting to 00000000000080dc
For which this link suggested using --entery-main switch. So now I have an executable. I want to thank you again. If you do see any problem in what I have done, please post something for me. it is gonna take a while for me to get this executable on my device.
I have 2 driver files.
dr1.c
dr2.c
dr1.c does an EXPORT_SYMBOL(func1).
dr2.c uses that via a definition in dr1.h
Both the dr1 and dr2 are compiled and object files are created.
However, in th last stage of kernel compilation, I get an error
undefined reference for func1 in dr2 but the dr2 object file is created.
I do not understand why the linking is not happening.
Basically the linking doesn't happen because the address of func1() which is defined in dr1.c is unknown to dr2.c.
There are two solutions to this problem :
1. Make the address known manually to the second file :
In this case let us assume that the modules dr1.c and dr2.c are present in different directories and has got its own Makefile. Firstly, compile the dr1 module. After its done, copy the Modules.symvers file to the directory containing dr2.c and then build the dr2 module. The Modules.symvers basically contains the address of the "exported symbols", which, by copying it to the destination of the other module, you are making it "known" and thus finally the linking happens.
2. Use a common Makefile for both the modules :
Put both the dr1.c and dr2.c in the same directory and create a common kernel Makefile for it. Make the following entry in the Makefile :
obj-m := dr1.o dr2.o
When this is done, both the files will be compiled, produces a common Modules.symvers file and linked accordingly.
Hope this helped.
dr1 was being compiled as a module
dr2 was being compiled into the kernel.
As a result the linking could not happen since dr1 is not part of vmlinux even though dr1 got compiled into a module without any error. I made dr2 into a module as well.
Also, I had to make sure that the kernel modules option is enabled in the config.
I am trying to modify the dynamic linker provided in the libc6(2.15-0ubuntu20.2) on a 64 bit Ubuntu machine.
So currently my code is using the same version of the glibc library. (I have downloaded the source code for the same and working on it). My question is that is it possible to modify and build only the linker source code which is present in glibc\elf\ directory without building the entire glibc library.
And if it is possible how can I make my test program to switch using the new version of dynamic linker that I have build myself instead of using the default unmodified linker.
Any pointers or suggestions are highly appreciated.
(If any more information is needed please let me know)
EDIT::
#constantius
I followed the steps in the post linked by you to build ld.so.
But I am getting following error on the make and I checked ld.so is not there in the elf.
The error is::
/var/services/homes/abhi/test/ld/eglibc-build/elf/librtld.os: In function `generic_getcwd':
/var/services/homes/abhi/test/ld/eglibc-2.15/elf/../sysdeps/posix/getcwd.c:356: undefined reference to `__closedir'
/var/services/homes/abhi/test/ld/eglibc-2.15/elf/../sysdeps/posix/getcwd.c:368: undefined reference to `__fdopendir'
/var/services/homes/abhi/test/ld/eglibc-2.15/elf/../sysdeps/posix/getcwd.c:384: undefined reference to `__readdir'
/var/services/homes/abhi/test/ld/eglibc-2.15/elf/../sysdeps/posix/getcwd.c:397: undefined reference to `rewinddir'
/var/services/homes/abhi/test/ld/eglibc-2.15/elf/../sysdeps/posix/getcwd.c:528: undefined reference to `__closedir'
/var/services/homes/abhi/test/ld/eglibc-2.15/elf/../sysdeps/posix/getcwd.c:490: undefined reference to `__closedir'
collect2: error: ld returned 1 exit status
make[2]: *** [/var/services/homes/abhi/test/ld/eglibc-build/elf/ld.so] Error 1
make[2]: Leaving directory `/var/services/homes/abhi/test/ld/eglibc-2.15/elf'
make[1]: *** [elf/subdir_lib] Error 2
make[1]: Leaving directory `/var/services/homes/abhi/test/ld/eglibc-2.15'
make: *** [all] Error 2
NOTE With the same infrastructure I can build and install the full GLIBC so I dont think there is an error with the infrastructure.
-- I guess the error is some where related to editing Makeconfig to all-subdirs = csu elf gmon io misc posix setjmp signal stdlib string time.
--Any suggestions on this..
SOLVED
Need to add dirent in the all-subdirs list in addition to what we edited before
Thanks
Citing this page. In case you don't get something, comment please — I'll try to explain.
Building
To compile Glibc (ld.so cannot be compiled independently) download and unpack Glibc source tarball.
1 Make sure the version of Glibc you downloaded is the same as the system's current one.
2 Make sure the environmental variable LD_RUN_PATH is not set.
3 Read the INSTALL and make sure all necessary tool chains (Make, Binutils, etc) are up-to-date.
4 Make sure the file system you are doing the compilation is case sensitive, or you will see weird errors like
/scratch/elf/librtld.os: In function `process_envvars':
/tmp/glibc-2.x.y/elf/rtld.c:2718: undefined reference to `__open'
...
5 ld.so should be compiled with the optimization flag on (-O2 is the default). Failing to do so will end up with weird errors (see Question 1.23 in FAQ)
6 Suppose Glibc is unpacked at
/tmp/glibc-2.x.y/
Then edit /tmp/glibc-2.x.y/Makefile.in: Un-comment the line
# PARALLELMFLAGS = -j 4
and change 4 to an appropriate number.
7 Since we are only interested in ld.so and not the whole Glibc, we only want to build the essential source files needed by ld.so. To do so, edit /tmp/glibc-2.x.y/Makeconfig: Find the line started with
all-subdirs = csu assert ctype locale intl catgets math setjmp signal \
...
and change it to
all-subdirs = csu elf gmon io misc posix setjmp signal stdlib string time
8 Find a scratch directory, say /scratch. Then
$ cd /scratch
$ /tmp/glibc-2.x.y/configure --prefix=/scratch --disable-profile
$ gmake
Since we are not building the entire Glibc, when the gmake stops (probably with some errors), check if /scratch/elf/ld.so exists or not.
ld.so is a static binary, which means it has its own implementation of standard C routines (e.g. memcpy, strcmp, etc) It has its own printf-like routine called _dl_debug_printf.
Testing
You can run the ld-linux.so directly. It will complain that this is probably not what you want (but you want exactly this) and offer you list of options with which you can run it. See also man ld-linux.so for debugging flags, i.e. there's LD_DEBUG environment variable you can define to see ld-linux.so debugging output.
While I'm not clear on whether the build system for glibc makes doing this easy, there's no fundamental reason why you can't build and use the glibc dynamic linker without building libc.so. I would peruse the top-level Makefile for ways to make this work.
As for testing it, there are two methods:
Explicitly invoke the dynamic linker to run a program, as in:
./ld-linux.so.2 a.out args ...
When linking your program, specify an alternate dynamic linker pathname (which will get stored in its PT_INTERP program header) by passing this option to the compiler driver:
-Wl,-dynamic-linker,/path/to/alternate/ld-linux.so.2
I would like to write a linux block device driver. The driver would not need to access the hardware so it can be in userspace.
To start, I have tried to build an example block device driver with this Makefile:
obj-m = sbd.o
KVERSION = $(shell pwd)
PWD = $(shell pwd)
all:
make -C /lib/modules/$(KVERSION)/build M=$(PWD) modules
I however get these errors which I do not know how to fix. Here is the stdout and stderr:
make -C /lib/modules/2.6.31-19-generic/build M=/home/andreas/sp/nivoa/src/driver/sbd modules
make[1]: Entering directory `/usr/src/linux-headers-2.6.31-19-generic'
CC [M] /home/andreas/sp/nivoa/src/driver/sbd/sbd.o
/home/andreas/sp/nivoa/src/driver/sbd/sbd.c:72: error: expected ‘)’ before ‘*’ token
/home/andreas/sp/nivoa/src/driver/sbd/sbd.c:128: warning: initialization from incompatible pointer type
/home/andreas/sp/nivoa/src/driver/sbd/sbd.c: In function ‘sbd_init’:
/home/andreas/sp/nivoa/src/driver/sbd/sbd.c:143: error: ‘sbd_request’ undeclared (first use in this function)
/home/andreas/sp/nivoa/src/driver/sbd/sbd.c:143: error: (Each undeclared identifier is reported only once
/home/andreas/sp/nivoa/src/driver/sbd/sbd.c:143: error: for each function it appears in.)
/home/andreas/sp/nivoa/src/driver/sbd/sbd.c:146: error: implicit declaration of function ‘blk_queue_hardsect_size’
make[2]: *** [/home/andreas/sp/nivoa/src/driver/sbd/sbd.o] Error 1
make[1]: *** [_module_/home/andreas/sp/nivoa/src/driver/sbd] Error 2
make[1]: Leaving directory `/usr/src/linux-headers-2.6.31-19-generic'
make: *** [all] Error 2
Any help on this would be greatly appreciated.
Thanks,
Andreas
There isn't an "official" way of doing block drivers in userspace, however people often do it by (ab)using the NBD driver to talk over a loopback network to a daemon which listens on a normal socket and speaks the NBD protocol. See the NBD docs for more info.
Your example is for a kernel-mode block device, which will need to be built as a kernel module. And as the kernel internals are always changing, it's presumably now incompatible.
Following MarkR's suggestion, it is even possible to talk the NBD protocol over an AF_UNIX socket pair, so no extra local daemon is needed. The program implementing this protocol will need to set up the socket pair and fork off a child. Both parent and child close one end of the socket pair. One of them starts taking requests on its end of the socket while the other one connects the NBD driver to its end of the socket.
Always looks at the first error:
In your case it looks like a problem with include files, e.g. request_queue_t is not defined.
Since this is a deprecated type, you are probably using a version of linux/blkdev.h that is newer than the code example.
Try adding typedef struct request_queue request_queue_t;
While using NBD, as suggested before, is nice, maybe a better way (used by, for example, virtualbox-fuse) is to make a FUSE filesystem that exports one file, which you can then use via losetup.
You can use NBD. Using nbdkit you can even write virtual block devices in shell script or other scripting languages (although stick to C if you want the best performance). I gave a talk about this topic at FOSDEM 2019 where I did a live demo writing a Linux kernel block device in shell script.
In addition to the above useful answers I would like to add that apart from NBD, there are also other ways where Linux Block I/O Layer can be used at userspace. Following are the additional options:
TCMU (TCM in Userspace) helps implementing custom SCSI (Small Computer System Interface) targets (block device) in user space.
BUSE (block device in userspace) build on the idea of Filesystem in Userspace (FUSE) allows the virtual block devices to run in userspace as well.