> Anyway in any case how does shell get the 'd' or anything from the > keyboard? > What are the exact steps? I'm a Linux kernel newbie, (although I have heavy embedded MCU coding background) but I can help with the general approach of this scenario. First, it's important to note that any interrupt handler should be as *short* as possible. This applies to any CPU/MCU system. Once the handler (ISR) has acted upon the event, it will have relevant data stored somewhere, which then the OS or "foreground" code can act upon. This is commonly referred to as "bottom half". For a keyboard handler, it will typically use a ring buffer (OSs will use queues). The ring buffer will have a pointer to the head (where the latest or newest data was stored) and the tail (where the oldest data resides). When head and tail are equal the ring buffer is empty. In your example, the head pointer will point to the character 'd' and the tail will be one behind. It's most convenient (and fastest) to assign a buffer size of a power of 2. Note that at this stage it's not per se necessary that further interrupts or task yielding occurs. The application code could do something as simple as polling whether there is data in the buffer by looking at the head/tail pointers on a frequent basis. In the case of an OS, the task of retrieving and processing the keyboard data will activate if it wasn't active. Where that keyboard data then is off to will depend on what shell/application/process is running. The received 'd' character might even just sit there in the buffer but no one is interested in it... Perhaps that gives a very general insight at machine level of what goes on. Also, wrt the discussion of non-preemptive kernel use : Note that many OSs *can* fairly efficiently operate without preemption. What Michi wrote is very true : >> The point behind a non preemtive kernel is that it process A will *not* >> be interrupted, if it is executing kernel code. 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) HTH Kris On Thu, 5 Mar 2009 19:06:35 -0500, sahlot arvind <asahlot@xxxxxxxxx> wrote: > Got it!.I have another question: > What are the exact steps when I press a key? Assume only one shell is > running and I press 'd': > 1. processor will get interrupted. > 2. it will jump to the common interrupt handler > 3. common interrupt handler will save the context of shell and will call > the > appropriate interrupt handler (driver's part) in this case keyboard driver > 4. key board interrupt handler will run and read the data from keyboard > memory or registers etc and then return to the common interrupt handler > 5. common interrupt handler will restore the context of shell > 6. shell will resume > > Now in the above scenario I am missing something and that is how the data > (from keyboard) in this case 'd' gets delivered to the shell. I mean I > understand up to the point where keyboard interrupt handler reads the data > from keyboard mem or registers but where does it put 'd' back? Does > keyboard > driver send 'd' to the display driver internally and then to shell? OR 'd' > is delivered to the shell and shell then sends it back to the display > driver > to display it onto the screen? > Anyway in any case how does shell get the 'd' or anything from the > keyboard? > What are the exact steps? > > Thanks a lot! > > On Thu, Mar 5, 2009 at 2:26 PM, Michael Blizek < > michi1@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote: > >> Hi! >> >> On 13:00 Thu 05 Mar , Pranav Peshwe wrote: >> > On Thu, Mar 5, 2009 at 11:48 AM, Michael Blizek < >> > michi1@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote: >> > >> > > Hi! >> > > >> > > On 23:47 Wed 04 Mar , sahlot arvind wrote: >> > > > Hi All, >> >> ... >> >> > > > 2. If kernel is not preemptible then do we really need a separate >> kernel >> > > > mode stack for each and every process? I mean cannot we use a >> > > > common >> > > kernel >> > > > mode stack for all and every process? I think we can because since >> only >> > > one >> > > > process could be in the kernel mode at a time, any process getting >> into >> > > > kernel mode can easily assume that the kernel mode stack is always >> free >> > > > whenever it gets into kernel mode. >> > > >> > > Maybe... However it would need at least one stack per cpu and making >> the >> > > kernel non preemptive is bad for system responsiveness. >> > > >> > >> > I think sleeping in the kernel will make using a common kernel stack >> > extremely difficult (if not theoretically impossible). >> > Suppose, while running some code in the kernel, process A goes to sleep >> > process B is scheduled. B will then use the stack for its own calls. If >> > B >> > too goes to sleep then there is no way that A can be run without B >> unwinding >> > the stack first. Even if we decide to save the stack pointer separately >> for >> > each process then, A will at some point, overwrite B's frames since >> > they >> > share the stack. >> > IMHO, the confusion lies in saying that 'only one process could be >> > in >> > the kernel mode at a time'. Although, on a uniprocessor machine only >> > one >> > process can be in the kernel mode at any given instant of time, more >> > than >> > one processes can be executing in kernel mode quasi-parallelly. >> >> The point behind a non preemtive kernel is that it process A will *not* >> be >> interrupted, if it is executing kernel code. If it can be interrupted, >> the >> kernel is preemptive. >> >> However, you have system calls like read() which have to go to sleep, >> even >> in a non preemtive kernel. So you need at least some extra for these >> cases. >> This makes sharing stacks more complex. >> >> -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 >> >> -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
