On Wed, Apr 15, 2009 at 6:51 PM, Peter Teoh <htmldeveloper@xxxxxxxxx> wrote: > Hi Pradeep, > > On Wed, Apr 15, 2009 at 6:59 AM, pradeep singh > <pradeep.rautela@xxxxxxxxx> wrote: >> On Wed, Apr 15, 2009 at 12:20 PM, Peter Teoh <htmldeveloper@xxxxxxxxx> wrote: >> [...] >>>> What I know is that there are only two types of contextes: process, and >>>> interrupt. Hardware interrupt handler and deferrable functions(including >>>> softirq and tasklete) run in interrupt context. >>>> >>> >>> well....hardware interrupt context is when the hardware IRQ flag is >>> still set, which will be turned off (via hardware - not software) when >>> u do a iret. >>> >>> software interrupt context is a kernel processing loop trying to clear >>> up all the remaining activities outstanding from hardware interrupt >>> context. >>> >>> and process context is when the kernel switch over to execute with >>> full pagetable addrespace ownership (see below). >>> >>> In Intel manual there is something called "software >>> interrupts".....nothing to do with anything mentioned here. >>> >>>>> >>>>> read this for further details (from LDDv3): >>>>> >>>>> http://lwn.net/images/pdf/LDD3/ch07.pdf >>>>> >>>>> within it explained what is a kernel thread. So basically while >>>>> running process A in kernel mode, it can be intercepted by any kernel >>>>> threads, and these kernel threads therefore "DOES NOT HAVE PROCESS >>>>> CONTEXT", as they are not related to the currently running process A, >>>> If these threads does not have process context, then what context are they in? >>>> hardware interrupt context? software interrupt context? Or you'll create another >>>> new context named "thread context"? >>>> >>> >>> Firstly, it is related to Intel hardware MMU/pagetable/CR3 mechanism. >>> In Linux kernel design, there is no change in the pagetables when >>> transition from kernel to user space (and vice versa) are made - >>> because of performance cost (called lazy-TLB). It is switch only >>> when there is a process switch - by changing the CR3. >>> >>> "No process context" actually means that the taskstruct's >>> mm_struct->mm is NULL. >> >> Hi Peter, I wonder saying no process context will be appropriate here? >> They do have a process context because scheduler does not differentiate between >> kernel threads and other processes AFAIK. right? >> > > Yes, u are right, kernel threads and processes are all schedulable. > > Let me quote another source for explanation: > > http://www.linuxquestions.org/linux/articles/Technical/Linux_Kernel_Thread > > "KERNEL THREADS > > Kernels can attain parallelism by spawning some operations in the > background. The kernel achieves this by delegating these operations to > the kernel threads. A kernel thread is a process that exists only in > kernel space and does not have access to user address space i.e. mm > pointer is NULL. Being an integral part of a kernel and running in a I doubt if this is true Peter. Kernel threads do have access to user space they just do not have an associated user space context . Why I so say is because of the following code snippet kernel_thread() - regs.ds = __USER_DS regs.es = __USER_ES So, if you are right then why set ds and es segments to __USER_DS in segment descriptors? Or did I misinterpret it? Thanks, --Pradeep > kernel address space, they have an access to kernel data structures. A > Kernel thread does not have a privilege over other processes and hence > they are also as schedulable and pre-emptable as any other process." > > read the article......very readable. thanks. > > > -- > Regards, > Peter Teoh > -- Pradeep -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
