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,
The point behind a non preemtive kernel is that it process A will *not* be
> > > 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.
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
--
http://linuxexplained.blogspot.com
