I have to write a linux module and I can't find a proper function to list all mounted file system and their information. I know command "df -T" can achieve this and sadly I can't use that. Is there a kernel function that can do this or other way?
Why not see the kernel code which fills /proc/mounts
mountstats_open() in base.c
refer get filesystem mount point in kernel module
Your code could open/read the /proc/mounts file, line by line. It contains everything that is mounted, including many mount points that you would not expect.
In general, the format is the same as the /etc/fstab file, but will also include all the mounts that the OS adds.
Related
I've written a character device driver that, I believe, should work.
I want to test the read/write functions. On another stack overflow question, apparently this can be done by writing to the device file in /dev and echoing the output.
I don't understand how this works:
When I load up my device driver by allocating a major number and calling mknod to create the file, is the file "open"? If it isn't open, then reading/writing shouldn't work like that from the command line, or so I thought?
What state is the device driver in when it has been initialized in /proc/devices and a file created in /dev?
Does this initialization need to happen before attempting to open the device file in a c program?
These answer are extremely difficult to find online, and many resources are outdated. Thanks
One good resource is Linux device driver. A shorter and simpler explanation can be found here.
When you create a file driver, you will implement some functions among file operations (fops):
open
close
read
write
seek
...
Not all function have to be implemented. If write is not implemented for instance, your device won't support writting.
When I load up my device driver by allocating a major number and calling mknod to create the file, is the file "open"?
When the /dev file is created, your module is only inited. A function like init_module is called
When the file is removed, your module is deinited. A function like module_cleanup is called.
What state is the device driver in when it has been initialized in /proc/devices and a file created in /dev?
In that case, the module is inited, the file are not open.
If it isn't open, then reading/writing shouldn't work like that from the command line, or so I thought?
When you read a file from command line, the file is open, read then closed, as a user, you don't have to care to open/close file explicitly.
Things are different if you are a C programmer, in that case, you explicitly have to open, read, close the files.
You can check that adding traces in your kernel code (using printk to print some info to kernel console, reading it with dmesg) or using strace that will trace the system calls.
Does this initialization need to happen before attempting to open the device file in a c program?
Let's resume:
The first function called will be module_init before it's called, the file doesnot exist in /dev
The last function called will be module_cleanup after it's called, the file doesnot exist in /dev
between init and cleanup, you can call the different open, close, read and write function.
Generally read/write are called between open and close.
I've recently learned about kernel modules and I was thinking on how to create one that does what cat /proc/cpuinfo does.
Is it possible to do this without opening/reading the file directly (fread)?
Thanks in advance!
/proc/cpuinfo output is generated by kernel code; you can check that code and do the same in your kernel module.
Code is located in fs/proc/cpuinfo.c
It references 'cpuinfo_op' object that is provided by architecture-dependent code, try 'grep cpuinfo_op arch' from toplevel directory of kernel source to locate it.
I wants to get the names of execute files in some directory in Linux.
How can I do it?
I tried to use opendir like this:
dir = opendir(directoryName);
I need to get only the names of the execute files.
I programming in C.
thanks :)
You should define what you mean by executable files.
That could be any file with its execute bit (it is the owner, group, or other) set. Then test with access(2) & X_OK and/or use stat(2).
That could also be only ELF executables. See elf(5); then the issue might be to check that a file could indeed be executed, which might be difficult (what about missing library dependencies? or ill-formed ELF files?). Maybe use libelf (and/or libmagic to do the equivalent of file(1) command).
To scan recursively a file tree, use nftw(3); to scan just a directory use opendir(3) & readdir(3) (don't forget the closedir!), then you'll probably need to build the complete file path from each directory entry (perhaps using snprintf(3) or asprintf(3))
See also Advanced Linux Programming
I'm running linux kernel no. 2.6.15.51 on a ubuntu system.
I created a custom system call and added it to the kernel (containing a struct), compiled, and booted into the new kernel. Now I'm trying to create a c file that calls that system call (for testing purposes). Because I have a struct declared in my system call file, I am including the header in my test file so I can use that same struct. However, when I try including my system call file (which makes a call to access_ok() method), I get an error saying asm/uaccess.h (the file where access_ok() is declared) does not exist. Any ideas why I could be having this problem? Thank you!
Consider the following Linux kernel dump stack trace; e.g., you can trigger a panic from the kernel source code by calling panic("debugging a Linux kernel panic");:
[<001360ac>] (unwind_backtrace+0x0/0xf8) from [<00147b7c>] (warn_slowpath_common+0x50/0x60)
[<00147b7c>] (warn_slowpath_common+0x50/0x60) from [<00147c40>] (warn_slowpath_null+0x1c/0x24)
[<00147c40>] (warn_slowpath_null+0x1c/0x24) from [<0014de44>] (local_bh_enable_ip+0xa0/0xac)
[<0014de44>] (local_bh_enable_ip+0xa0/0xac) from [<0019594c>] (bdi_register+0xec/0x150)
In unwind_backtrace+0x0/0xf8 what does +0x0/0xf8 stand for?
How can I see the C code of unwind_backtrace+0x0/0xf8?
How to interpret the panic's content?
It's just an ordinary backtrace, those functions are called in reverse order (first one called was called by the previous one and so on):
unwind_backtrace+0x0/0xf8
warn_slowpath_common+0x50/0x60
warn_slowpath_null+0x1c/0x24
ocal_bh_enable_ip+0xa0/0xac
bdi_register+0xec/0x150
The bdi_register+0xec/0x150 is the symbol + the offset/length there's more information about that in Understanding a Kernel Oops and how you can debug a kernel oops. Also there's this excellent tutorial on Debugging the Kernel
Note: as suggested below by Eugene, you may want to try addr2line first, it still needs an image with debugging symbols though, for example
addr2line -e vmlinux_with_debug_info 0019594c(+offset)
Here are two alternatives for addr2line. Assuming you have the proper target's toolchain, you can do one of the following:
Use objdump:
locate your vmlinux or the .ko file under the kernel root directory, then disassemble the object file :
objdump -dS vmlinux > /tmp/kernel.s
Open the generated assembly file, /tmp/kernel.s. with a text editor such as vim. Go to
unwind_backtrace+0x0/0xf8, i.e. search for the address of unwind_backtrace + the offset. Finally, you have located the problematic part in your source code.
Use gdb:
IMO, an even more elegant option is to use the one and only gdb. Assuming you have the suitable toolchain on your host machine:
Run gdb <path-to-vmlinux>.
Execute in gdb's prompt: list *(unwind_backtrace+0x10).
For additional information, you may checkout the following resources:
Kernel Debugging Tricks.
Debugging The Linux Kernel Using Gdb
In unwind_backtrace+0x0/0xf8 what the +0x0/0xf8 stands for?
The first number (+0x0) is the offset from the beginning of the function (unwind_backtrace in this case). The second number (0xf8) is the total length of the function. Given these two pieces of information, if you already have a hunch about where the fault occurred this might be enough to confirm your suspicion (you can tell (roughly) how far along in the function you were).
To get the exact source line of the corresponding instruction (generally better than hunches), use addr2line or the other methods in other answers.