its been a while since i came here, reason being..... _looking_ into kernel source code, just to figure out how many things have changed since i last had a peek in to it. Thanks to blog post by Anikita, which actually pushed me to look into a few things, cos of which my progress on the work front has been reduced by 80% or so....
First of all: Kprobes,
I have been using this feature quite a bit, this time i decided to actually dig into it a bit deeper to try and understand the layer in the kernel, _main_ reason being, kprobes is still not supported under ARM arch. Quite frankly, i should actually congratulate IBM and its folks for having done great job with Kprobes, i haven't had much luck trying to digest the whole part, but i have been steady going atleast.
The features i like most are pre function(a function that is executed before the probe address is executed) and post function(function after the probe address is executed), this actually together gives a developer most of the required debug information, which makes it a lot simpler and obviously faster to nail the bug.
After having looked at the code, i quite impressed the way its been hacked, especially register_kprobe function_.
if (p->symbol_name) { if (p->addr) return -EINVAL; kprobe_lookup_name(p->symbol_name, p->addr); } if (!p->addr) return -EINVAL; p->addr = (kprobe_opcode_t *)(((char *)p->addr)+ p->offset); if (!kernel_text_address((unsigned long) p->addr) || in_kprobes_functions((unsigned long) p->addr)) return -EINVAL; p->mod_refcounted = 0; /* * Check if are we probing a module. */ probed_mod = module_text_address((unsigned long) p->addr); if (probed_mod) { struct module *calling_mod = module_text_address(called_from); /* * We must allow modules to probe themself and in this case * avoid incrementing the module refcount, so as to allow * unloading of self probing modules. */ if (calling_mod && calling_mod != probed_mod) { if (unlikely(!try_module_get(probed_mod))) return -EINVAL; p->mod_refcounted = 1; } else probed_mod = NULL; } the code path considers every aspect, ......if you're a kernel developer, _you_ already know about it, if you aspire to be one, Kprobes is something that you should look into, google for more, there are some wonderful docs as well as examples which can help you get started with that.
second RT_PREEMPT:
This is another aspect i have been waiting to play with. Over the years Ingo Molnar and other have spent time and effort in giving Linux the feature of RT_PREEMPT, if your not sure why, here's why in brief,
All cause of Latencies, like
Interrupt Latency
Wakeup Latency
Scheduling Latency
Priority Inversion
Interrupt Inversion etc....
The patch i download is really very huge, i have started to go through the source, but its gonna take while for me to actually understand it completely, but, its interesting.
A few things that kept me hooked are,
Threaded Interrupts:
Interrupts do not run under Interrupt Context anymore, they run as normal threads, which means they run as normal processes, which implies, Process Context, so the next time there is an interrupt, no context switch, basically these are threads with pre-defined priorities which generally are higher than normal processes. So, this feature actually reduces interrupt latency(time the interrupt occurs to the time its serviced) drastically, this may lead to many question. So lets consider an example,
_suupose the code path in the kernel generated an interrupt, a thread is created to service this interrupt line(one thread per interrupt line, even if its a shared interrupt, look at the code for more), after which do_irqd is woken up and interrupt exits. Here the interrupt is only masked, the interrupt is yet to be handled, which i suppose you know how it happens.
Something that actually got me facinated to work on the _kernel_ source was what you can do with Linux at runtime, atleast i started by writing _hello world_ linux kernel module, this feature of passing runtime information to the kernel image is still the most interesting feature for me, so when i looked the Preempt code, there i found it again
int kernel_preemption = 1;
static int __init preempt_setup (char *str)
{
if (!strncmp(str, "off", 3)) {
if (kernel_preemption) {
printk(KERN_INFO "turning off kernel preemption!\n");
kernel_preemption = 0;
}
return 1;
}
if (!strncmp(str, "on", 2)) {
if (!kernel_preemption) {
printk(KERN_INFO "turning on kernel preemption!\n");
kernel_preemption = 1;
}
return 1;
}
get_option(&str, &kernel_preemption);
return 1;
}
__setup("preempt=", preempt_setup);
There's a lot more to it than i have understood it, next is probably spin_lock implementation and Priority Inversion. Will have more to talk about.
There is a document that found, which even mentions about the complexity _priority inheritance_ algorithm, and it actually having problems, since the priority to the threads are pre-assigned. I haven't the read the doc completely, so willl not talk much on it, may be next time.
Interesting --> Fear of long words _is_ Hippopotomonstrosesquippedaliophobi i seriously have this phobia!!
1 comments: