Is there a simple way to, within a running Linux kernel module, to determine the full file name for the .ko file (ie: /lib/modules/$(uname -r)/kernel/drivers/mymodule.ko) associated with the module, without traversing procfs, but instead, just relying on internal structures/lists available in kernel space code?
You cannot obtain path to the module file within the kernel: the kernel doesn't store it. Moreover, the kernel even doesn't know that path.
There are two syscalls for load a kernel module: init_module and finit_module (both are defined in kernel/module.c). The first one accepts pointer to user space area, where module image resides (user space should read module file into that area before). The second one accepts descriptor to the module's file, but this descriptor is used only for read content of the file, and isn't stored.
No.
First: your module may have been compiled into the kernel, and thus won't have a file path.
Second: Loading kernel modules from files takes place in userspace. The kernel is passed a module as a data buffer, using the init_module system call -- it's theoretically possible that this data was never loaded from a file at all. (For instance, one can imagine a module loader that loads modules from the network, or from a compressed archive.)
Related
I understand every bit of the C compilation process (how the object files are linked to create the executable). But about the loader itself (which starts the program running) I have a few doubts.
Is the loader part of the kernel?
How exactly is the ./firefox or some command like that loaded? I mean you normally type such commands into the terminal which loads the executable I presume. So is the loader a component of the shell?
I think I'm also confused about where the terminal/shell fits into all of this and what its role is.
The format of an executable determines how it will be loaded. For example executables with "#!" as the first two characters are loaded by the kernel by executing the named interpreter and feeding the file to it as the first argument. If the executable is formatted as a PE, ELF, or MachO binary then the kernel uses an intrepter for that format that is built in to the kernel in order to find the executable code and data and then choose the next step.
In the case of a dynamically linked ELF, the next step is to execute the dynamic loader (usually ld.so) in order to find the libraries, load them, abd resolve the symbols. This all happens in userspace. The kernel is more or less unaware of dynamic linking, because it all happens in userspace after the kernel has handed control to the interprter named in the ELF file.
The corresponding system call is exec. It is part of the kernel and in charge of cleaning the old address space that makes the call and get a new fresh one with all materials to run a new code. This is part of the kernel because address space is a kind of sandbox that protect processes from others, and since it is critical it is in charge of the kernel.
The shell is just in charge of interpreting what you type and transform it to proper structures (list or arrays of C-strings) to pass to some exec call (after having, most of the time, spawned a new process with fork).
I'm reading LDD3. In chapter 8, I could not understand this paragraph:
An example of a function in the kernel that uses vmalloc is the create_module system
call, which uses vmalloc to get space for the module being created. Code and data of
the module are later copied to the allocated space using copy_from_user. In this way,
the module appears to be loaded into contiguous memory.
Why is copy_from_user used? Aren't we in kernel space only?
Recall that kernel modules are loaded by the insmod (or modprobe) command, which runs in user space. These commands load the kernel module from disk into memory, then pass it to the kernel, which must use copy_from_user() to copy that to kernel memory.
I want to save some information in a kernel module. I have seen similar question to mine here in stackoverflow, however mine is slightly different. Assuming I am using this code to write in a /proc file. How should I call it inside one of my kernel module? I have a custom kernel module called mymodule which is not the main file (does not have init_module()) inside it the below function is called. In this case what should be the input value to the function like value of file? Basically is it possible to create a /proc file inside a kernel module?
int procfile_write(struct file *file, const char *buffer, unsigned long count,
void *data)
It is definitely possible to add a proc entry in a kernel module but you might be misunderstanding how file handling works in the kernel.
When you create a file in proc, you're not actually 'creating' a file like you would in userspace. You're registering a few callbacks that are called when userspace programs request your file.
That means, when userspace programs request a read, your file read callback has to provide data. When a userspace program requests a write, your file write callback has to handle it.
If you want to use it like a conventional file to store information, you have to allocate the required space and have your read callback copy data from there.
sample driver created and loaded successfully, in that a user defined function is written, it does some actions. i need to write a user program that calls the user defined function in the driver module.
need help in following cases.
How can i get access to the driver code from a user program ?.
How can i call a function that written in kernel module, from the user program ?.
thanks.
You can make your driver to react on writes (or if necessary, ioctl) to a /dev/xxx file or a /proc/xxx file. Also, you can create a new syscall, but that's more of a toy as the module would only work on custom built kernels.
Edit: try http://www.faqs.org/docs/kernel/x571.html (on character device drivers.)
It depends on what your function does, but in general:
If you want to store and show properties in the form of values (e.g. current brightness of a backlight), the standard way of doing would be using sysfs: http://kernel.org/doc/Documentation/filesystems/sysfs.txt
If you want to write/read values from a device (real or virtual), export memory or IO regions of a device to user space, or more generally control a device (e.g. setting resolution of a camera and capturing frames), you would use a character or block devices with the read/write/mmap and ioctl functions: http://luv.asn.au/overheads/chrdev-talk.html
Finally if your function just controls something from the kernel, then sysfs or procfs should be the way to go. I am not sure why people are still using procfs nowadays, except for misc devices maybe.
So in general, you need to export your kernel functions to user space through files, by defining hooks that will be called when the file is opened, read, written (to copy data from/to user space), mmap'ed (to share memory areas without copying) or when an ioctl is invoked (to perform more general control).
VDSO:
http://en.wikipedia.org/wiki/VDSO
Kernel mode Linux:
http://www.yl.is.s.u-tokyo.ac.jp/~tosh/kml/
for Qn.1:
read/write/ioctl see file_operations
for Qn.2:
1) system calls
2) driver - ioctl
I have a program(A) and there is anather executable file(B) in the same folder. I must call function from this anther program(B) in my program(A). And all this must be done in dos. How can i do it or what i should read to do this? Please help.
If your two programs are separate executables files then will most likely run in two different processes, You cannot just call functions accross two different processes, you need to use some Inter Process communication mechansim.
You need to start understanding the basics & make a start somewhere and this seems to be a good place to do so.
Since you mention DOS as the target platform, DOS is a non-preempted single user single processing environment but still TSR's in DOS environment emulate the phenomenon of multiprocessing. To implement IPC in DOS you will have to arrange for the TSR to collar a software interrupt, and then communicate with it through that.
MS-Dos is a 16 bit OS. The executables that run in MS-Dos come in two flavours: ".exe" and ".com". Think of the ".com" as a ".exe" with lots of default values assumed by the OS. The ".exe" files contain a header which is read by the OS to determine various parameters. One of these parameters is the entry point address. Only one entry point address is defined (and for a ".com" it is always cs:0x100) and that is the address the OS jumps to when the program has been loaded.
MS-Dos has functions to load another executable and run it, but it can only run from the address given in the header. No other function address is exported so you can't just call some arbitrary function in the other executable. There is no DLL system in MS-Dos.
So, in order to call some arbitrary function in the second executable, you need to create your own DLL style system. This is not trivial since the OS uses a segmented memory model, that is, the memory is divided into 64k pages and addresses are formed from the segment address added to an offset, e.g. segment*16 + offset. So, there are 2^12 ways to express the same physical address. During the loading process, MS-Dos has to fix-up these segment values to reflect the actual location in memory the program has been loaded to. Remember, in MS-Dos there is no virtual memory. If you were to create your own DLL system, you will need to do this fixing-up yourself for code that's bigger than 64k (code+data less than 64k can ignore segments and treat all address as just 16bit offsets).
If you knew the addres, loading the ".exe" using the MS-Dos API would still be tricky as you'd need to know the CS (code segment) address the executable has been loaded to.