Hi...
Commenting those two lines out don't even start init. While using __KERNEL_DS instead of __USER_DS starts init then causes a `Panic: Segment violation at 0x8049798 - Sleeping for 30 seconds'. It may then have an important role than just mimicing user processes, right ? What makes me wonder is that as said in Understanding Linux Kernel (v3): When CPL (Current Privelege level) is equal to 3, the ds register must contain the segment selector of the user data segment. When it's equal to zero, the ds register must contain the segment selector of the kernel data segment. So how come running a kernel thread with DS = __USER_DS ?
Bunch of thanks for your effort to confirm it. Now since you mention it stucked on firing up "init" process, I come to the other hypotheses. Commenting the ds assignment IMHO makes the kernel assign 0 or undetermined data (depending whether the pt_regs struct is created in stack or data area), and that will makes it points either GDT #0 or non existing GDT entry. Both are wrong, of course Now, KERNEL_DS also fails. It tells us that __USER_DS is the only answer. And when we need it? When our CPL is 3 (user mode). But we know that kernel threads operates in CPL=0 (kernel/supervisor mode). So, I think, it isn't really the kernel thread(s) which complains, but the other user mode process. How come? When kernel thread is switched out and user mode process gets in, several steps of context switching happen. One of them of restoring register condition, for instance EIP so kernel can start the process wherever it was once preempted. pt_regs, IMHO, represents this soon-to-be-restored registers, so imagine if __KERNEL_DS is popped back to DS register and user mode operates in CPL=3. Screwed, right? So, I guess that's my idea. Feel free to comment. regards, Mulyadi -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
