Hi Michi, Thanks for pointing this out. Of course I was describing an RTOS in general, but it's good to know now that one can pre-empt user space code w/o pre-empting kernel code. I thought that - given the general question - an initial general RTOS vs. "superloop" programming rundown would clarify better how keyboard data can/could be handled.. :-) Because I came from the lowest level (HW, then ASM coding, then C coding on memory constrained targets), sometimes I wonder if that actually really is an advantage. It seems the task of really learning Linux kernel coding still is just as daunting anyhow.... (rather than having a PC coding background, coming from the highest level and then going down). Best Regards, Kris -----Original Message----- From: kernelnewbies-bounce@xxxxxxxxxxxx [mailto:kernelnewbies-bounce@xxxxxxxxxxxx] On Behalf Of Michael Blizek Sent: Friday, 6 March 2009 5:04 PM To: microbit@xxxxxxxxxxxxxxxxxxxxxx Cc: Kernelnewbies Subject: Re: About Kernel preemption and kernel mode stack Hi! On 12:15 Fri 06 Mar , microbit@xxxxxxxxxxxxxxxxxxxxxx wrote: ... > In this case it's common to use co-operative scheduling. This means that > when a task does not need further execution, it must relinquish control > back to the scheduler. I personally find this a real pig to program like > that, but it does allow very compact targets (altough this is more for the > embedded world) Just because you do not want to preempt running kernel code, it does not mean that you have to do co-operative scheduling. You can still preempt user space code. You can see the "big kernel lock" for more details (but do *not* use it in new code - people try to get rid of it). -Michi -- programing a layer 3+4 network protocol for mesh networks see http://michaelblizek.twilightparadox.com -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
