October 2012 - kernelnewbies@kernelnewbies.org

Re: creating own syscall on 2.6.37.3 and getting error on compilaton...
by Filipe Rinaldi Oct. 22, 2012

Oct. 22, 2012

On 22 October 2012 01:10, <rgonzale(a)darkterminal.net> wrote: > Ah the kernel/sched directory was added in 3.3. I'm using 2.6.37.3. > > > -Tristan > On Sun, Oct 21, 2012 at 11:14:32PM +0100, Filipe Rinaldi wrote: >> On 21 October 2012 21:28, <rgonzale(a)darkterminal.net> wrote: >> > I'm trying to implement my own system call on Linux kernel 2.6.37.3 using this guide. >> > >> > http://enzam.wordpress.com/2011/03/2...nel-ubuntu-os/ >> > >> > Here's the code that I have for kernel/mysystemcalls.c >> > It just takes an int for an argument and then spits out the PIDs for the process that is running on that CPU. >> > Code: >> > >> > #include<linux/linkage.h> >> > #include<linux/cpumask.h> >> > asmlinkage long sys_current_pid(int i) { >> > struct rq *rq; >> > int num_cpu; >> > num_cpu = num_online_cpus(); >> > if(i <= 0 || i > num_cpu) >> > return -1; >> > >> > rq = cpu_rq(i); >> > if(rq->curr != NULL) >> > return rq->curr->pid; >> > else >> > return -1; >> > } >> > >> > But on kernel compilation I get this. >> > Code: >> > >> > kernel/mysystemcalls.c: In function 'sys_current_pid': >> > kernel/mysystemcalls.c:12: error: implicit declaration of function 'cpu_rq' >> > kernel/mysystemcalls.c:12: warning: assignment makes pointer from integer without a cast >> > kernel/mysystemcalls.c:13: error: dereferencing pointer to incomplete type >> > kernel/mysystemcalls.c:14: error: dereferencing pointer to incomplete type >> > make[1]: *** [kernel/mysystemcalls.o] Error 1 >> > make[1]: *** Waiting for unfinished jobs.... >> > >> > The definition for cpu_rq() is in kernel/sched.c. >> >> sched.c contains the implementation, the definition is in >> sched/sched.h, you should #include that header. >> >> > Here's the pertinent piece of Makefile in kernel/Makefile >> > Code: >> > >> > # >> > # Makefile for the linux kernel. >> > # >> > >> > obj-y = sched.o fork.o exec_domain.o panic.o printk.o \ >> > cpu.o exit.o itimer.o time.o softirq.o resource.o \ >> > sysctl.o sysctl_binary.o capability.o ptrace.o timer.o user.o \ >> > signal.o sys.o kmod.o workqueue.o pid.o \ >> > rcupdate.o extable.o params.o posix-timers.o \ >> > kthread.o wait.o kfifo.o sys_ni.o posix-cpu-timers.o mutex.o \ >> > hrtimer.o rwsem.o nsproxy.o srcu.o semaphore.o \ >> > notifier.o ksysfs.o pm_qos_params.o sched_clock.o cred.o \ >> > async.o range.o jump_label.o >> > obj-y += mysystemcalls.o >> > >> > I would think that since sched.o(the first c file that gets compiled) has the definition for the cpu_rq() then mysystemcalls.c should be able to see that function. What am I missing? >> > >> >> You don't have a *link* error. It is not that the linker can't find cpu_rq(). >> It is the compiler that does not understand the cpu_rq() definition. >> Try to include the header. >> >> Cheers, >> -Filipe Humm, on 2.6.37 this is a private macro in sched.c. I suppose you could use "current->pid". "current" is a macro that returns the current task's structure: http://lxr.linux.no/linux+v2.6.37.3/arch/x86/include/asm/current.h#L17 -Filipe

1 0

What rationale behind physical and virtual kernel memory layout ?
by telenn barz Oct. 22, 2012

Oct. 22, 2012

Hi all, This a vast topic. But I believe it's worthwhile exposing in greater detail the "Why this design has been chosen ?", before the "How this design has been implemented ?". And I think this is a common lack (or at least not enough developed) in documentations, even in the more outstanding of them. Let's try to be more precise : A] About the direct mapping of the first 896MB of the virtual kernel space to the first 896MB of the physical memory Thus the kernel is able to handle a big virtual memory area mapped to a zone of contiguous physical addresses. This is a need for some peripheral devices which are unable to deal with paged memory. So all right, I can understand that (ref: "Avoiding - and fixing - memory fragmentation<http://lwn.net/Articles/211505/>" at lwn.net) But this article also says this is required for large kernel data structures... Q: ...Here I don't get the point : why wouldn't it be possible for the kernel to handle its structures through paged memory not necessarily physically contiguous ? In the bible "Understanding the Linux Kernel" third edition, at section "8.3 Non-contiguous Memory Area Management" it is written : "[...] it is preferable to map areas into sets of contiguous page frames, thus making better use of the cache and achieving lower average memory access times". Q: Is this assertion still valid on modern architecture ? Can please someone explain in further detail the theory behind it, or point me to relevant documentations ? Q: Do you see any other reason for this physically-contiguous memory requirement ? B] About the 3G/1G split of process' virtual address space on 32-bit architecture The article "Virtual Memory I: the problem <http://lwn.net/Articles/75174/>" at lwn.net says it has to see with the TLB : by sharing the process' virtual space, we also share the TLB and thus we avoid a costly TLB flush at each user-space to kernel-space switch. The article invokes this reason of degradation performance when talking about the 4G/4G split patch (from Ingo Molnar). Q: In the 4G/4G split case, I don't see why we have to necessarily flush the TLB when switching from user-space to kernel-space ? Why the TLB couldn't be shared across one user-space to kernel-space switch, and be flushed only every two switches ? The TLB is small, Ok... but is it really a matter of TLB size ? I mean the kernel can rely on big pages for backing its virtual space : this is already the case for Intel Pentium (ref: "Understanding the Linux Kernel" third edition) which uses 4MB pages, or for Freescale e500v2/e500mc family which uses 256MB pages. On this architecture, if it had to map 4GB of physical memory, it could even use a single huge page, thus occupying a single page table entry, and so a single TLB entry... Thanks to anyone for bringing a gentle breeze of cleverness on my cloudy brain, Telenn

2 3

Query on CodingStyle: indentation
by Kumar amit mehta Oct. 22, 2012

Oct. 22, 2012

Hi, I've a query regarding the coding style for Linux Kernel code. I'm reading the CodingStyle under Documentation and what I've understood is that I shouldn't be using spaces for indentation purposes and should use tabs of width 8 characters. Quoting from the same document: "Outside of comments, documentation and except in Kconfig, spaces are never used for indentation, and the above example is deliberately broken." However, Is it correct to replace each tab stroke by 8 spaces ? I use vim editor and I've put following under $HOME/.vimrc file: <snip> set tabstop=8 set shiftwidth=8 set expandtab <snip> In past I've seen that some application have different interpretation of tabs and hence sometimes even If I've done proper indentation using tab, the code appears unindented, and therefore In order to make sure that I'm moving 8 characters upon hitting tab, I've put the above rules under my .vimrc file. Please let me know If I should remove these from my .vimrc file and rely on tab instead. -Amit

3 4

Fwd: creating own syscall on 2.6.37.3 and getting error on compilaton...
by Filipe Rinaldi Oct. 21, 2012

Oct. 21, 2012

On 21 October 2012 21:28, <rgonzale(a)darkterminal.net> wrote: > I'm trying to implement my own system call on Linux kernel 2.6.37.3 using this guide. > > http://enzam.wordpress.com/2011/03/2...nel-ubuntu-os/ > > Here's the code that I have for kernel/mysystemcalls.c > It just takes an int for an argument and then spits out the PIDs for the process that is running on that CPU. > Code: > > #include<linux/linkage.h> > #include<linux/cpumask.h> > asmlinkage long sys_current_pid(int i) { > struct rq *rq; > int num_cpu; > num_cpu = num_online_cpus(); > if(i <= 0 || i > num_cpu) > return -1; > > rq = cpu_rq(i); > if(rq->curr != NULL) > return rq->curr->pid; > else > return -1; > } > > But on kernel compilation I get this. > Code: > > kernel/mysystemcalls.c: In function 'sys_current_pid': > kernel/mysystemcalls.c:12: error: implicit declaration of function 'cpu_rq' > kernel/mysystemcalls.c:12: warning: assignment makes pointer from integer without a cast > kernel/mysystemcalls.c:13: error: dereferencing pointer to incomplete type > kernel/mysystemcalls.c:14: error: dereferencing pointer to incomplete type > make[1]: *** [kernel/mysystemcalls.o] Error 1 > make[1]: *** Waiting for unfinished jobs.... > > The definition for cpu_rq() is in kernel/sched.c. sched.c contains the implementation, the definition is in sched/sched.h, you should #include that header. > Here's the pertinent piece of Makefile in kernel/Makefile > Code: > > # > # Makefile for the linux kernel. > # > > obj-y = sched.o fork.o exec_domain.o panic.o printk.o \ > cpu.o exit.o itimer.o time.o softirq.o resource.o \ > sysctl.o sysctl_binary.o capability.o ptrace.o timer.o user.o \ > signal.o sys.o kmod.o workqueue.o pid.o \ > rcupdate.o extable.o params.o posix-timers.o \ > kthread.o wait.o kfifo.o sys_ni.o posix-cpu-timers.o mutex.o \ > hrtimer.o rwsem.o nsproxy.o srcu.o semaphore.o \ > notifier.o ksysfs.o pm_qos_params.o sched_clock.o cred.o \ > async.o range.o jump_label.o > obj-y += mysystemcalls.o > > I would think that since sched.o(the first c file that gets compiled) has the definition for the cpu_rq() then mysystemcalls.c should be able to see that function. What am I missing? > You don't have a *link* error. It is not that the linker can't find cpu_rq(). It is the compiler that does not understand the cpu_rq() definition. Try to include the header. Cheers, -Filipe

1 0

creating own syscall on 2.6.37.3 and getting error on compilaton...
by rgonzale＠darkterminal.net Oct. 21, 2012

Oct. 21, 2012

I'm trying to implement my own system call on Linux kernel 2.6.37.3 using this guide. http://enzam.wordpress.com/2011/03/2...nel-ubuntu-os/ Here's the code that I have for kernel/mysystemcalls.c It just takes an int for an argument and then spits out the PIDs for the process that is running on that CPU. Code: #include<linux/linkage.h> #include<linux/cpumask.h> asmlinkage long sys_current_pid(int i) { struct rq *rq; int num_cpu; num_cpu = num_online_cpus(); if(i <= 0 || i > num_cpu) return -1; rq = cpu_rq(i); if(rq->curr != NULL) return rq->curr->pid; else return -1; } But on kernel compilation I get this. Code: kernel/mysystemcalls.c: In function 'sys_current_pid': kernel/mysystemcalls.c:12: error: implicit declaration of function 'cpu_rq' kernel/mysystemcalls.c:12: warning: assignment makes pointer from integer without a cast kernel/mysystemcalls.c:13: error: dereferencing pointer to incomplete type kernel/mysystemcalls.c:14: error: dereferencing pointer to incomplete type make[1]: *** [kernel/mysystemcalls.o] Error 1 make[1]: *** Waiting for unfinished jobs.... The definition for cpu_rq() is in kernel/sched.c. Here's the pertinent piece of Makefile in kernel/Makefile Code: # # Makefile for the linux kernel. # obj-y = sched.o fork.o exec_domain.o panic.o printk.o \ cpu.o exit.o itimer.o time.o softirq.o resource.o \ sysctl.o sysctl_binary.o capability.o ptrace.o timer.o user.o \ signal.o sys.o kmod.o workqueue.o pid.o \ rcupdate.o extable.o params.o posix-timers.o \ kthread.o wait.o kfifo.o sys_ni.o posix-cpu-timers.o mutex.o \ hrtimer.o rwsem.o nsproxy.o srcu.o semaphore.o \ notifier.o ksysfs.o pm_qos_params.o sched_clock.o cred.o \ async.o range.o jump_label.o obj-y += mysystemcalls.o I would think that since sched.o(the first c file that gets compiled) has the definition for the cpu_rq() then mysystemcalls.c should be able to see that function. What am I missing? -Tristan

1 0

where are the bug ?
by Fan Yang Oct. 21, 2012

Oct. 21, 2012

HI ALL: I just run a module on my machine, but it can't work. When the module run the kernel will painc. I don't know where is wrong. This is my code: 1 #include<linux/module.h> 2 #include<linux/kernel.h> 3 #include<linux/init.h> 4 #include<linux/sched.h> 5 6 int input = 1; 7 module_param (input, int, S_IRUGO); 8 9 static int __init printvma_init (void) 10 { 11 struct vm_area_struct *p, *start; 12 int i; 13 struct task_struct *thread; 14 15 thread = current; 16 17 while (1) 18 { 19 if (thread->pid == input) 20 break; 21 thread = list_entry (thread->tasks.next, struct task_struct, tasks); 22 } 23 p = thread->mm->mmap; 24 25 do{ 26 printk ("%lx\t%lx\t%s\n", p->vm_start,\ 27 p->vm_end, p->vm_file->f_path.dentry->d_iname); 28 p = p->vm_next; 29 }while (p != NULL); 30 31 printk ("vm_file address is:%d\tf_path address is:%d\ 32 \tname is:%s",& p->vm_file->f_path,\ 33 p->vm_file->f_path.dentry->d_iname); 34 35 printk ("info from the kernel space:%s\n", thread->comm); 36 return 0; 37 } 38 39 static void __exit printvma_exit (void) 40 { 41 printk ("the module will leave the kernel space..\n"); 42 } 43 44 module_init (printvma_init); 45 module_exit (printvma_exit); 46 MODULE_LICENSE ("GPL"); what's wrong? thanks

5 10

more on work queues -- why is deprecated "flush_scheduled_work" still used?
by Robert P. J. Day Oct. 20, 2012

Oct. 20, 2012

followup to my earlier post looking for clarification -- i was a bit confused by the kernel-wide nature of the flush_scheduled_work() call, and poked around until i found this: $ git show 3d7851b3 commit 3d7851b3cdd43a734e5cc4c643fd886ab28ad4d5 Author: Tejun Heo <tj(a)kernel.org> Date: Fri Oct 15 09:51:08 2010 -0400 oprofile: Remove deprecated use of flush_scheduled_work() flush_scheduled_work() is deprecated and scheduled to be removed. ... snip ... so even as far back as 2010, that routine had been labelled as "deprecated", but there's still a fair bit of it in the source tree. in fact, it's still being *added*: $ git blame drivers/infiniband/hw/mlx4/cm.c ... snip ... 3cf69cc8 (Amir Vadai 2012-08-03 08:40:47 +0000 392) if (!need_flush) 3cf69cc8 (Amir Vadai 2012-08-03 08:40:47 +0000 393) flush_scheduled_work(); /* make sure all timers were flushed */ ... snip ... is there anything that talks about the current state of this kernel-wide work queue, and the proper way to use it? it certainly seems like anyone (including drivers) that truly need a work queue should be creating their own, no? 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

Finding the interrupt vector of a given IRQ
by Mark Farnell Oct. 20, 2012

Oct. 20, 2012

In the kernel, how can I find out the interrupt vector number of a given IRQ (for example, IRQ7)? Within the kernel module, I would like to manually set the IRQ using the assembly code: asm("int $<irq vector>"); and let the IRQ handler installed by a different module catch that interrupt. Is this possible? Thanks! Mark

7 10

if flush_scheduled_work() is allegedly overkill, why do drivers use it?
by Robert P. J. Day Oct. 19, 2012

Oct. 19, 2012

working my way through work queues and read this in workqueue.h: /** * flush_scheduled_work - ensure that any scheduled work has run to completion. * * Forces execution of the kernel-global workqueue and blocks until its * completion. * * Think twice before calling this function! It's very easy to get into * trouble if you don't take great care. Either of the following situations * will lead to deadlock: * * One of the work items currently on the workqueue needs to acquire * a lock held by your code or its caller. * * Your code is running in the context of a work routine. * * They will be detected by lockdep when they occur, but the first might not * occur very often. It depends on what work items are on the workqueue and * what locks they need, which you have no control over. * * In most situations flushing the entire workqueue is overkill; you merely * need to know that a particular work item isn't queued and isn't running. * In such cases you should use cancel_delayed_work_sync() or * cancel_work_sync() instead. */ and yet, there are quite a few drivers that do just that: $ grep -rw flush_scheduled_work drivers drivers/scsi/scsi_scan.c: flush_scheduled_work(); drivers/scsi/qla2xxx/qla_target.c: flush_scheduled_work(); drivers/leds/leds-blinkm.c: flush_scheduled_work(); drivers/acpi/osl.c: * which invoke flush_scheduled_work/acpi_os_wait_events_complete drivers/staging/olpc_dcon/olpc_dcon.c: flush_scheduled_work(); drivers/staging/rtl8192u/r8192U_core.c:// flush_scheduled_work(); drivers/staging/wlan-ng/prism2usb.c: flush_scheduled_work(); drivers/staging/iio/light/tsl2563.c: flush_scheduled_work(); drivers/staging/iio/light/tsl2563.c: flush_scheduled_work(); drivers/staging/rtl8712/usb_intf.c: flush_scheduled_work(); drivers/message/fusion/mptscsih.c: flush_scheduled_work(); drivers/rtc/rtc-dev.c: flush_scheduled_work(); drivers/rtc/rtc-88pm860x.c: flush_scheduled_work(); drivers/misc/mei/main.c: flush_scheduled_work(); drivers/misc/mei/main.c: flush_scheduled_work(); ... snip, even more after this ... so what's up with that? it seems inconsistent to describe that kernel-wide routine as "overkill" while a number of drivers continue to use it. rday -- ======================================================================== Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ========================================================================

2 2

Query on kernel module Makefile
by Kumar amit mehta Oct. 19, 2012

Oct. 19, 2012

I came across the following information in ~Documentation/kbuild/makefiles.txt <snip> --- 3.7 Compilation flags ccflags-y, asflags-y and ldflags-y These three flags apply only to the kbuild makefile in which they are assigned. They are used for all the normal cc, as and ld invocations happening during a recursive build. Note: Flags with the same behaviour were previously named: EXTRA_CFLAGS, EXTRA_AFLAGS and EXTRA_LDFLAGS. They are still supported but their usage is deprecated. ccflags-y specifies options for compiling with $(CC). Example: # drivers/acpi/Makefile ccflags-y := -Os ccflags-$(CONFIG_ACPI_DEBUG) += -DACPI_DEBUG_OUTPUT <snip> So My understanding is that we should be getting rid of these three flags (EXTRA_CFLAGS, EXTRA_AFLAGS and EXTRA_LDFLAGS) from Makefiles under kernel sources and also anywhere outside the kernel build system(e.g. our loadable modules). For learing purpose, I'm trying to maintain the ldd3 examples with the latest kernel sources and I see that the Makefiles under the ldd3 examples have something like this: <snip from original Makefile> EXTRA_CFLAGS += $(DEBFLAGS) -I$(LDDINC) .....some rules here......... ............................. depend .depend dep: $(CC) $(EXTRA_CFLAGS) -M *.c > .depend <snip from original Makefile> I'm planning to update such occurances of EXTRA_CFLAGS as: <snip from modified Makefile> ccflags-y += $(DEBFLAGS) -I$(LDDINC) .....some rules for target here......... ........................................ depend .depend dep: $(CC) $(ccflags) -M *.c > .depend <snip from modified Makefile> With the above change, the module compilation, load, unload etc works fine, but I'm not sure how this make 'depend' works and how to check if the rules for resolving auto dependency is written correctly. -Amit

1 0