I'm reading the online book about Linux Kernel drivers, which looks very obsolete to me. For example, the Linux Cross Reference can't find a variable gendisk_head (in kernel 3.13), which is supposed to point to a list of gendisk structures, available inside the kernel.
How can I list all the currently allocated gendisk structures from inside the kernel 3.13?
Take a look at the following code:
void __init printk_all_partitions(void)
{
struct class_dev_iter iter;
struct device *dev;
class_dev_iter_init(&iter, &block_class, NULL, &disk_type);
while ((dev = class_dev_iter_next(&iter))) {
struct gendisk *disk = dev_to_disk(dev);
Related
I am trying to figure out how to get the process descriptor from a PID.
From http://www.linuxforums.org/forum/kernel/153873-getting-task_struct-process-using-its-pid.html, for Linux kernel 2.4
static inline struct task_struct *find_task_by_pid(int pid)
{
struct task_struct *p, **htable = &pidhash[pid_hashfn(pid)];
for(p = *htable; p && p->pid != pid; p = p->pidhash_next)
;
return p;
}
The link seems to say that pidhash[pid_hashfn(pid)] is a pointer to a task_struct object whose PID is value pid.
But that doesn't seem to be true from the book Understanding The Linux Kernel, which talks about Linux kernel 2.6.11. I am not sure if the relevant code is the same in 2.6.11 and in 2.4. From the book, I learned that pidhash[pid_hashfn(pid)] has type hlist_head, which is a pointer to an hlist_node object. The hlist_node object is pids[0].pid_chain of a task_struct object. Then how can I obtain the task_struct object from pidhash[pid_hashfn(pid)]?
Note that
I am asking this just for the purposes of reading Understanding the Linus Kernel (Linux kernel 2.6.11), so I am not asking about the recent Linux kernel versions, although it doesn't hurt that you can also mention how it is done in the recent Linux kernel versions.
I guess the difficulty I have here is related to my previous question Whose address shall the node of a linked list store: other node, or data structure having a node as a field?
Thanks.
In kernel 2.6.11 task_struct contains array pids[PIDTYPE_MAX] so that given task placed in several hash-tables simultaniously.
pidhash contains pointers to PIDTYPE_MAX hash-tables. pidhash[i] is a pointer to beginning of i-th hash-table. Thus, pidhash[type][pid_hashfn(nr)] is a pointer to linked list.
It is better to find struct pid * to entry in task's [pids[type]] element with given pid type type and pid nr using kernel function find_pid(type, nr).
Then you can convert (non-NULL) pointer to struct pid into pointer to struct task_struct using container-of-based macro pid_task.
I have some question.
I try to read some VFS attributes, for example s_magic value in struct super_block.
but I cant read s_magic.
This is my code.
#include<stdio.h>
#include<fcntl.h>
#include<unistd.h>
#include<linux/fs.h>
int main()
{
int fd;
char boot[1024];
struct super_block sb;
fd = open("/dev/fd", O_RDONLY);
read(fd, boot, 1024);
read(fd, &sb, sizeof(struct super_block);
printf("%x\n", sb.s_magic);
close(fd);
return 0;
}
so, This code does't work with some error.
In this error, storage size of ‘sb’ isn’t known and invalid application of ‘sizeof’ to incomplete type ‘struct super_block’
Thank you.
That's because your linux/fs.h does not contain super_block declaration. That's because you want to include linux/fs.h from Linux kernel but actually include linux/fs.h from Linux userspace. Supply -I <include path> option to gcc like this
gcc -I /usr/src/kernels/$(uname -r)/include
BUT!
You will get a million of errors because you can't just include kernel headers in your userspace program - you don't have all type and struct definitions.
The kernel headers are not written with user space in mind, and they
can change at any time. The proper way for user-space applications to
interface with the kernel is by way of the C library, which provides
its own structures and, when necessary, translates them into whatever
the current kernel expects. This separation helps to keep user-space
programs from breaking when the kernel changes.
(source http://lwn.net/Articles/113349/)
So you have to revise your code.
P.S. I've given you and explanation why your code is not working, but I don't know how you can read super_block in userspace. You better ask another question regarding filesystem superblock API.
In Linux device driver development, the file_operations structure uses struct module *owner.
What is the use of this structure when we always initialize it with THIS_MODULE?
When can this field be set to NULL?
This field tells who is owner of struct file_operations. This prevents module to get unloaded when it is in operation. When initialized with THIS_MODULE current module holds the ownership on it.
Minimal runnable example
Whenever you create a kernel module, the kernel's build machinery generates a struct module object for you, and makes THIS_MODULE point to it.
This struct contains many fields, some of which can be set with module macros such as MODULE_VERSION.
This example shows how to access that information: module_info.c:
#include <linux/module.h>
#include <linux/kernel.h>
static int myinit(void)
{
/* Set by default based on the module file name. */
pr_info("name = %s\n", THIS_MODULE->name);
pr_info("version = %s\n", THIS_MODULE->version);
return 0;
}
static void myexit(void) {}
module_init(myinit)
module_exit(myexit)
MODULE_VERSION("1.0");
MODULE_LICENSE("GPL");
Dmesg outputs:
name = module_info
version = 1.0
Some MODULE_INFO fields can also be "accessed" in the following ways:
cat /sys/module/module_info/version
modinfo /module_info.ko | grep -E '^version:'
Since the address of that struct module object must be unique across all modules, it serves as a good argument for fops.owner as mentioned at: https://stackoverflow.com/a/19468893/895245. Here is a minimal example of that usage.
Tested in Linux kernel 4.16 with this QEMU + Buildroot setup.
[1] struct module *owner is commonly used at some structures and is not an operation at all; it is a pointer to the module that "owns"the structure. This field is used to prevent the module from being unloaded while its operations are in use. Almost all the time, it is simply initialized to THIS_MODULE, a macro defined in
< linux/module.h> .
.
[2] I would not recommend you to set it to null, because it may lead to driver malfunction and other problems. Instead, use the good practices of linux kernel development.
In some architectures the ".owner" was removed, so, make sure your distro and architecture still using it.
I hope it helps your understanding.
References: LDD3, kernel newbies.
file_operation is one of the main structures that used to connect the device numbers and the file operations of a driver.
There are lots of function pointer in the structure. The first pointer is struct module *owner which is not a function pointer at all but points to a structure module defined in the <linux/module.h>.
On initializing to THIS_MODULE, it holds the ownership of the module.
One of the main reasons to initialize struct module *owner to THIS_MODULE to prevent the module from getting unloaded while in use.
My question is about linux device model. I did some digging myself in the source code and found that the device model works around many structures out of which some of them are:
struct device
struct device_driver
struct bus_type
There are more related to power management.
But when I looked into the char drivers implemented in linux kernel (or if I implement my own char driver) linux kernel is only implementing "struct device" and all other structures are just NULL. I have checked this through some debugging and with friendly neighbourhood API printk().
So my question is then why char drivers are not completely following the device model?
Also which drivers are completely following linux device model?
Linux Device Model uses kobject as it's base which act as a glue to held it together.
The structures you mentioned come at a layer above kobject.
So, we can say that kobject is something that you will (almost) never come across but is still embedded everywhere.
And char drivers are no excuse:
struct cdev {
struct kobject kobj;
struct module *owner;
const struct file_operations *ops;
struct list_head list;
dev_t dev;
unsigned int count;
};
All drivers are following device model even without you know it, hence char drivers are no exception here too.
Look at implementation of cdev_add() and you will get your answer.
I suggest you go through this article and dig again inside LDM code.
I have a simple question: when i have to copy a structure's content from userspace to kernel space for example with an ioctl call (or viceversa) (for simplicity code hasn't error check):
typedef struct my_struct{
int a;
char b;
} my_struct;
Userspace:
my_struct s;
s.a = 11;
s.b = 'X';
ioctl(fd, MY_CMD, &s);
Kernelspace:
int my_ioctl(struct inode *inode, struct file *filp, unsigned int cmd,
unsigned long arg)
{
...
my_struct ks;
copy_from_user(&ks, (void __user *)arg, sizeof(ks));
...
}
i think that size of structure in userspace (variable s) and kernel space (variable ks) could be not the same (without specify the __attribute__((packed))). So is a right thing specifing the number of byte in copy_from_user with sizeof macro? I see that in kernel sources there are some structures that are not declared as packed so, how is ensured the fact that the size will be the same in userspace and kernelspace?
Thank you all!
Why should the layout of a struct be different in kernel space from user space? There is no reason for the compiler to layout data differently.
The exception is if userspace is a 32bit program running on a 64bit kernel. See http://www.x86-64.org/pipermail/discuss/2002-June/002614.html for a tutorial how to deal with this.
The userspace structure should come from kernel header, so struct definition should be the same in user and kernel space. Do you have any real example ?
Of course, if you play with different packing options on two side of an ABI, whatever it is, you are in trouble. The problem here is not sizeof.
If your question is : does packing options affect binary interface, the answer is yes.
If your question is, how can I solve a packing mismatch, please provide more information