August 2012 - kernelnewbies@kernelnewbies.org

where is the "/sys/bus" kobject created?
by Robert P. J. Day Aug. 24, 2012

Aug. 24, 2012

i'm currently writing a tutorial on sysfs and kobjects, and an early section will explain where all the top level kobjects under /sys come from. most of them are fairly obvious. first, a lot of them are global kobjects, as in: $ grep -r "struct kobject.*_kobj;" * arch/x86/platform/uv/uv_sysfs.c:struct kobject *sgi_uv_kobj; arch/x86/include/asm/uv/bios.h:extern struct kobject *sgi_uv_kobj; /* /sys/firmware/sgi_uv */ arch/s390/hypfs/inode.c:static struct kobject *s390_kobj; arch/powerpc/platforms/pseries/power.c:struct kobject *power_kobj; arch/powerpc/platforms/pseries/mobility.c:static struct kobject *mobility_kobj; drivers/parisc/pdc_stable.c:static struct kobject *stable_kobj; drivers/base/hypervisor.c:struct kobject *hypervisor_kobj; drivers/base/core.c:static struct kobject *dev_kobj; ... snip ... and the top-level objects have a common creation call: $ grep -r "kobject_create_and_add.*NULL" * arch/powerpc/platforms/pseries/power.c: power_kobj = kobject_create_and_add("power", NULL); block/genhd.c: block_depr = kobject_create_and_add("block", NULL); drivers/base/hypervisor.c: hypervisor_kobj = kobject_create_and_add("hypervisor", NULL); drivers/base/core.c: dev_kobj = kobject_create_and_add("dev", NULL); drivers/base/firmware.c: firmware_kobj = kobject_create_and_add("firmware", NULL); drivers/staging/speakup/kobjects.c: accessibility_kobj = kobject_create_and_add("accessibility", NULL); fs/namespace.c: fs_kobj = kobject_create_and_add("fs", NULL); kernel/ksysfs.c: kernel_kobj = kobject_create_and_add("kernel", NULL); kernel/power/main.c: power_kobj = kobject_create_and_add("power", NULL); $ but i don't see the call that creates the kobject for "/sys/bus", and i've poked around, checking other kobject creation variations. any hints? rday -- ======================================================================== Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ========================================================================

1 0

How to understand lowmem_reserve in a zone?
by Parmenides Aug. 24, 2012

Aug. 24, 2012

Hi, I have a question about the reseved page frames in a zone. The physical memory is splitted into some node, which is further divied into some zone. For each zone, the kernel try to reserve some page frames to statisfy requests on low memory condition. There is a lowmem_reserve[] in a zone descriptor, its defined like: struct zone { .... unsigned long lowmem_reserve[MAX_NR_ZONES]; ... }; It is obvious that lowmem_reserve[] contains MAX_NR_ZONES elements. But, I think just a interger is enough to record the number of a zone's reserved page frames. Why do we have to use a array?Furthermore, lowmem_reserve[] merely stand for the amount. How does the kernel mark a page frame to be reserved?

2 1

adding entries to swapper_pg_dir after boot
by Asim Aug. 24, 2012

Aug. 24, 2012

Hi, I am trying to address a range of special addresses in the kernel that are not visible(addressable) to memory at boot time. I create a whole in the virtual address space and then I want to try to add page table entries to the kernel page table for these VA<->MY(PA) translation. (Let me know if there is a better way to do this) I was wondering if anyone knew how do I go about this. I can access the kernel page tables from swapper_pg_dir. How do I add pgd enteries for these virtual addresses? Any sample code/reference will be helpful. Thanks, Asim

1 0

mmap
by Christophe Hauser Aug. 23, 2012

Aug. 23, 2012

Hi all, When tracking mmaps from LSM with the following hook: static int file_mmap(struct file *file, unsigned long reqprot, unsigned long prot, unsigned long flags, unsigned long addr, unsigned long addr_only); I often get: file = NULL flags = 0x0 (MAP_FILE) prot = 0x0 (PROT_NONE) I am wondering what is the use for mmap with MAP_FILE and PROT_NONE together ? Not sure how to interpret that ? -- Christophe

2 1

How is initramfs_data.cpio handled by the kernel during boot?
by stl Aug. 23, 2012

Aug. 23, 2012

Hello, I have a question concerning initramfs support. When the kernel is built, a initramfs_data.cpio archive is created in linux-2.6.x/usr. This archive can be compressed by selecting the compression type in .config (gzip, bzip2, lzma or lzo). When the kernel build is finished, what does this initramfs_data.cpio become? Is it put somewhere is vmlinux executable? If so, where? Is it expanded in the INITRAMFS section defined in the vmlinux.lds.S Finally, how is this cpio archive handled by the kernel? Thanks in advance for your help.

1 0

workqueues in suspend
by Stefan Karlsson Aug. 22, 2012

Aug. 22, 2012

Hello, I wonder what happens to non-freezable workqueues during suspend. I can't see that they are mentioned anywhere in the kernel with respect to suspend. /Stefan

1 0

Need KGDB Ethernet patch for kernel 3.4.7 and 2.6.38
by Vivek Panwar Aug. 21, 2012

Aug. 21, 2012

Hi, Can please someone point me the path for KGDB Ethernet patches for Kernel 2.6.38 and 3.4.7. Thanks Vivek

1 0

why does proc_create_data() test for "S_ISDIR(mode)"?
by Robert P. J. Day Aug. 21, 2012

Aug. 21, 2012

poking around proc file headers and sources for purposes of documentation and noticed something that seems odd. the standard way to create a proc file is: proc_create(char* name, umode_t mode, ... *parent, etc); again, that's for creating *files* -- directories under /proc are typically created with something like proc_mkdir(). so far, so good. what this means so far is that the "mode" parameter to proc_create() should represent simple file permissions -- there should be no bit setting indicating a directory. in proc_fs.h, we see the wrapper: static inline struct proc_dir_entry *proc_create(const char *name, umode_t mode, struct proc_dir_entry *parent, const struct file_operations *proc_fops) { return proc_create_data(name, mode, parent, proc_fops, NULL); } so proc_create() turns around and calls proc_create_data(), again with a "mode" value that should represent the mode for only a file, not a directory. and yet, when we get to proc_create_data() in fs/proc/generic.c, we read: struct proc_dir_entry *proc_create_data(const char *name, umode_t mode, struct proc_dir_entry *parent, const struct file_operations *proc_fops, void *data) { struct proc_dir_entry *pde; nlink_t nlink; if (S_ISDIR(mode)) { <----- ???????? if proc_create() and, subsequently, proc_create_data() are called for *only* files, when will that test ever succeed? it's not hurting anything, but it seems completely redundant. eventually, that routine calls the internal routine __proc_create(), and it's *that* routine that appears to be the central point for all proc file creation, files and directories both. but the directory test in proc_create_data() seems to be some sort of historical holdover. just for fun, i went looking for any call to proc_create_data() that somehow specified a directory, and this is what i got: $ grep -r "proc_create_data.*DIR" * $ in other words, nothing. admittedly, i haven't searched as thoroughly as i might have, but ... thoughts? is that S_ISDIR test as redundant as i think it is? rday -- ======================================================================== Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ========================================================================

1 0

understanding Debugfs
by swair shah Aug. 20, 2012

Aug. 20, 2012

I'm trying to understand the use of debugfs with the use of this sample program. #include <linux/init.h> #include <linux/debugfs.h> #include <linux/module.h> #include <linux/fs.h> #define len 200 u64 intvalue,hexvalue; struct dentry *dirret,*fileret,*u64int,*u64hex; char ker_buf[len]; int filevalue; /* read file operation */ static ssize_t myreader(struct file *fp, char __user *user_buffer, size_t count, loff_t *position){ return simple_read_from_buffer(user_buffer, count, position, ker_buf, len); } /* write file operation */ static ssize_t mywriter(struct file *fp, const char __user *user_buffer, size_t count, loff_t *position){ if(count > len ) return -EINVAL; return simple_write_to_buffer(ker_buf, len, position, user_buffer, count); } static const struct file_operations fops_debug = { .read = myreader, .write = mywriter, }; static int __init init_debug(void) { /* create a directory by the name dell in /sys/kernel/debugfs */ dirret = debugfs_create_dir("dell", NULL); /* create a file in the above directory This requires read and write file operations */ fileret = debugfs_create_file("text", 0644, dirret, &filevalue, &fops_debug); /* create a file which takes in a int(64) value */ u64int = debugfs_create_u64("number", 0644, dirret, &intvalue); if (!u64int) { printk("error creating int file"); return (-ENODEV); } /* takes a hex decimal value */ u64hex = debugfs_create_x64("hexnum", 0644, dirret, &hexvalue ); if (!u64hex) { printk("error creating hex file"); return (-ENODEV); } return (0); } module_init(init_debug); static void __exit exit_debug(void){ debugfs_remove_recursive(dirret); } module_exit(exit_debug); Shouldn't it create a dir named 'dell' in sys/kernel/debug ?. (debugfs is mounted.) Can someone explain the use of debugfs or may be point to some good resources? thanks! swair

3 2

need some clarifications concerning rootf mounting
by stl Aug. 20, 2012

Aug. 20, 2012

Hello all, I need some explanations concerning the ways to mount rootf during boot. I have read some documents (notably the very useful How to use initramfs by Rob Landley) and dug into the source code, but some doubts remain. If I well understood, there is 2 differents procedures to mount the rootfs: - using the old way: init ramdisk - using the initramfs support (which appears to be really more efficient) The fonction "populate_rootfs()" seems to be a crucial point of the procedure: it calls a first time "unpack_to_roofs()" with __initramfs_start and __initramfs_size as arguments, and if initrd_start is not NULL, calls one more time "unpack_to_rootfs()" with initrd_start and (initrd_end-initrd_start) as arguments. What's really happening during the first unpack_to_rootfs() ? Does the kernel unpack the iniramfs.cpio (created either by supplying a valid cpio one or a config file through CONFIG_INITRAMFS_SOURCE) from __initramfs_start (defined in vmlinux.lds.S)? If I aim to use initramfs support, should I do something with initrd_start/end and CONFIG_BLK_DEV_RAM stuffs? Thanks in advance for your help and clarifications. Regards

2 4