From mboxrd@z Thu Jan 1 00:00:00 1970 From: mohit89mlnc@gmail.com (mohit verma) Date: Sun, 20 Mar 2011 13:08:44 +0530 Subject: Common signal handler system call In-Reply-To: <1300571006.23326.18.camel@thorin> References: <1300534267.23326.10.camel@thorin> <1300571006.23326.18.camel@thorin> Message-ID: To: kernelnewbies@lists.kernelnewbies.org List-Id: kernelnewbies.lists.kernelnewbies.org On Sun, Mar 20, 2011 at 3:13 AM, Bernd Petrovitsch < bernd@petrovitsch.priv.at> wrote: > On Sam, 2011-03-19 at 19:48 +0530, mohit verma wrote: [...] > > is there any need of raise() system call if we have kill() system > > call which is capable of sending signals to the process itself? > > No there is no need. But at least on Fedora 13, `man 2 raise` doesn't > give anything but `man 3 raise` does. The simple interpretation is that > that raise() is a C library function and not a system call. > Yeah , i almost forgot that. thanks. But here is a solid example ( i think) : clone(2) and fork(2) system calls. clone() is internally handled by fork handlers. > > Well, you can implement your idea as a library function too. > Apart from the "just for fun" factor or to learn how to implement a new > system call, I see no real gain to move that into kernel. > I think it should be there in kernel not because it is my idea but for good reasons (personally think so). > > > Actually there are lots of examples of this type .Some of them are for > > compatibility reasons and still some are "i dont know why." :) > > FullACK. The system calls were defined ages ago and who knows now what > and why people (and *who*) defined it, so some cruft should be expected. > And since such design decision tend to live for ages, more people should > throw their thoughts in ..... > [...] > Bernd > -- > Bernd Petrovitsch Email : bernd at petrovitsch.priv.at > LUGA : http://www.luga.at > > -- ........................ *MOHIT VERMA* -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20110320/b8ce4165/attachment.html