On Sat, Dec 31, 2005 at 05:04:24PM +0700, Mulyadi Santosa wrote: > Hello Rajaram...and hello Mr McKinney .... > > I am sorry for CC-ing this e-mail to you, Mr McKinney. I have some > difficulties when analyzing why set_task_state() gives different effect > compared to simply use something like task_struct->state=TASK_RUNNING. > Since I read your article about instruction reordering in LJ, maybe you > can kindly shed a light here..... set_task_state() ensures that no later memory references will be reordered, either by the CPU or by the compiler, to occur before the assignment to task_struct->state. A simple assignment does -not- make this guarantee. In a UP (uniprocessor) kernel, there will be almost no difference between the two, since there is no other CPU to be confused by the misordering. In an SMP kernel, memory barriers can make a big difference. Most code does not need explicit memory barriers, since locking primitives contain them. Explicit memory barriers, such as the one used in set_task_state(), are needed either when (1) working without locks or (2) interacting with device registers on weakly ordered machines. Hope that helps! Thanx, Paul > > <Raja2> Thanks for the information, although I am too new to these > > concepts to appreciate them. > > Actually, I am not expert on this kind of issue...but since this is > still related with process management, I am kinda interested to study > it. > > > <Raja2> Thats interesting to know ! but we were able to send SIGKILL > > when it is in kernel mode ? > > Yep, sending signal can be done anywhere, but signal handler is only > executed on the way back to user space. but this doesn't neglect the > fact that process which sleeps in kernel mode (interruptible, of > course) can be woken up by sending it a signal. Also, you can check > pending signal everytime you are woken up in kernel space and do the > needed action (in other word, you can simulate "signal handler"). > > Check the thread between Toni, /me and Jan Hudec about the adventure on > signal handling when doing network code hack :) > > > <Raja2> Thanks for your encouragement. But I am just a new guy who > > is dreaming to reach some level :) I am interested in knowing more > > about you in terms of your kernel work etc..I saw that you are > > associated with Linux Journal etc. Any advice for me to develop > > myself in understanding the kernel and contributing to it..? I am > > just currently following the book by Robert Love :) <Raja2> > > Hehe, I am just a poor writer, nothing more :) > > Well, like the proverb says "practice makes perfect" :) But I can > suggest several tips you can try: > 1. Book is a great resource, but don't forget that you have the source > of the kernel and can explore it freely. read and study it as many as > you can. > 2. Do discussion with people , especially one who is more knowledgable > than you. This mailing list, #kernelnewbies IRC chatroom are good place > to do discussion. You can also go to #osdev on Freenode for general OS > discussion (not just Linux). The more you do discussion, the more you > know your own weakness and other people's strenght. Believe it or not, > just by reading postings on kernelnewbies, I study faster than reading > a book! > 3. Don't be afraid to do mistake when hacking the kernel. There are > virtual machines to help! Recovering from even the worst system corrupt > in virtual machine is just a matter of replacing the disk image with > the fresh one :) > 4. Never feel you're already on the top of the mountain. Once you get > this sense, be aware, that's the sign your brain reject to learn > something new. > 5. Specialize! At the beginning, take a quick look on every OS aspect > (scheduler, memory management, and so on). Once you get the basic idea > of all those things, decide which one you want to specialize. yes, I > see several genius people who is able to crunch every aspects of OS > like chewing gum, but that's rare. So, realizing our brain's limit, go > pick an OS aspect and study it deeper. naturally, as OS is a complex > thing, you will slowly understand the other aspect just because it is > related with the OS aspect you currently specialize at. > > Hope it helps > > regards > > Mulyadi > > -- Kernelnewbies: Help each other learn about the Linux kernel. Archive: http://mail.nl.linux.org/kernelnewbies/ FAQ: http://kernelnewbies.org/faq/
