Common signal handler system call

Common signal handler system call

[mohit verma]

Hi  folks,

AFAIK there is not particular system call in Linux  systems that can
register a number of signals (signal numbers) at once and provide a common
signal handler for all of the assembled signals. I know doing this may be
hardly required in practice. But i think this type of system call should be
in Linux systems which can serve handler functionality on some of signals.

Please tell me the flaws proposing something like this.
-- 
........................
*MOHIT VERMA*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20110319/9ecae177/attachment.html 

Fwd: Common signal handler system call

[mohit verma]

---------- Forwarded message ----------
From: mohit verma <mohit89mlnc@gmail.com>
Date: Sat, Mar 19, 2011 at 1:24 AM
Subject: Common signal handler system call
To: kernelnewbies <kernelnewbies@nl.linux.org>


Hi  folks,

AFAIK there is not particular system call in Linux  systems that can
register a number of signals (signal numbers) at once and provide a common
signal handler for all of the assembled signals. I know doing this may be
hardly required in practice. But i think this type of system call should be
in Linux systems which can serve handler functionality on some of signals.

Please tell me the flaws proposing something like this.
-- 
........................
*MOHIT VERMA*




-- 
........................
*MOHIT VERMA*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20110319/412f241c/attachment.html 

Fwd: Common signal handler system call

[mohit verma]

Hi  folks,

AFAIK there is not particular system call in Linux  systems that can
register a number of signals (signal numbers) at once and provide a common
signal handler for all of the assembled signals. I know doing this may be
hardly required in practice. But i think this type of system call should be
in Linux systems which can serve handler functionality on some of signals.

Please tell me the flaws proposing something like this. i want to work on
this tiny problem. :)
-- 
........................
*MOHIT VERMA*




-- 
........................
*MOHIT VERMA*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20110319/3fd53bb8/attachment.html 

Common signal handler system call

[Manish Katiyar]

On Fri, Mar 18, 2011 at 1:11 PM, mohit verma <mohit89mlnc@gmail.com> wrote:
> Hi ?folks,
> AFAIK there is not particular system call in Linux ?systems that can
> register a number of signals (signal numbers) at once and provide a common
> signal handler for all of the assembled signals.

Did you try giving a common signal handler for two different signals ?

> I know doing this may be
> hardly required in practice.

Why not....for example... I want to print "quitting...." error msg if
I get SIGINT or SIGQUIT.


> But i think this type of system call should be
> in Linux systems which can serve handler functionality on some of signals.
> Please tell me the flaws proposing something like this. i want to work on
> this tiny problem. :)
> --
> ........................
> MOHIT VERMA
>
>
>
> --
> ........................
> MOHIT VERMA
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
>



-- 
Thanks -
Manish

Common signal handler system call

[mohit verma]

On Sat, Mar 19, 2011 at 2:00 AM, Manish Katiyar <mkatiyar@gmail.com> wrote:

> On Fri, Mar 18, 2011 at 1:11 PM, mohit verma <mohit89mlnc@gmail.com>
> wrote:
> > Hi  folks,
> > AFAIK there is not particular system call in Linux  systems that can
> > register a number of signals (signal numbers) at once and provide a
> common
> > signal handler for all of the assembled signals.
>
> Did you try giving a common signal handler for two different signals ?
>
Yes i did.

>
> > I know doing this may be
> > hardly required in practice.
>
> Why not....for example... I want to print "quitting...." error msg if
> I get SIGINT or SIGQUIT.
>

Ok. i think these messages are for debugging purpose. But anyway let  it be
common. :)

>
>
> > But i think this type of system call should be
> > in Linux systems which can serve handler functionality on some of
> signals.
> > Please tell me the flaws proposing something like this. i want to work on
> > this tiny problem. :)
> > --
> > ........................
> > MOHIT VERMA
> >
> >
> >
> > --
> > ........................
> > MOHIT VERMA
> >
> > _______________________________________________
> > Kernelnewbies mailing list
> > Kernelnewbies at kernelnewbies.org
> > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
> >
> >
>
>
>
> --
> Thanks -
> Manish
>



-- 
........................
*MOHIT VERMA*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20110319/4f887c4c/attachment-0002.html 

Common signal handler system call

[Bernd Petrovitsch]

On Sam, 2011-03-19 at 02:42 +0530, mohit verma wrote: 
> On Sat, Mar 19, 2011 at 2:00 AM, Manish Katiyar <mkatiyar@gmail.com>
> wrote:
>         On Fri, Mar 18, 2011 at 1:11 PM, mohit verma
>         <mohit89mlnc@gmail.com> wrote:
>         > Hi  folks,
>         > AFAIK there is not particular system call in Linux  systems
>         that can
>         > register a number of signals (signal numbers) at once and
>         provide a common
>         > signal handler for all of the assembled signals.
>         
>         
>         Did you try giving a common signal handler for two different
>         signals ? 
> Yes i did. 
>         
>         > I know doing this may be
>         > hardly required in practice.
>         
>         
>         Why not....for example... I want to print "quitting...." error
>         msg if
>         I get SIGINT or SIGQUIT. 

Call sigaction() two times ....

> Ok. i think these messages are for debugging purpose. But anyway let
>  it be common. :) 

That's the problem: It is not common. And if the set of signals is
probably different for all these cases.

What's the drawback of the current situation?
It you you have the (IMHO) uncommon situation where you want to use the
same signal handler for different signals, you can easily call
sigaction() for all of them separately and be done. This is usually done
one per application so there is no point in speeding it up.

And just adding one system-call to cope with a rarely used operation
which can easily be simulated with other existing ones is a waste of
time for development and RAM on each host.

>         > But i think this type of system call should be
>         > in Linux systems which can serve handler functionality on
>         some of signals.
>         > Please tell me the flaws proposing something like this. i
>         want to work on
>         > this tiny problem. :)

What is the semantic of an error?
At least one signal registration fails or all failed or some failed?

And what is the application expected to do if it actually failed (for
whatever reason).

But feel free to implement it and play around!

Bernd
-- 
Bernd Petrovitsch                  Email : bernd at petrovitsch.priv.at
                     LUGA : http://www.luga.at

Common signal handler system call

[mohit verma]

On Sat, Mar 19, 2011 at 5:01 PM, Bernd Petrovitsch <
bernd@petrovitsch.priv.at> wrote:

> On Sam, 2011-03-19 at 02:42 +0530, mohit verma wrote:
> > On Sat, Mar 19, 2011 at 2:00 AM, Manish Katiyar <mkatiyar@gmail.com>
> > wrote:
> >         On Fri, Mar 18, 2011 at 1:11 PM, mohit verma
> >         <mohit89mlnc@gmail.com> wrote:
> >         > Hi  folks,
> >         > AFAIK there is not particular system call in Linux  systems
> >         that can
> >         > register a number of signals (signal numbers) at once and
> >         provide a common
> >         > signal handler for all of the assembled signals.
> >
> >
> >         Did you try giving a common signal handler for two different
> >         signals ?
> > Yes i did.
> >
> >         > I know doing this may be
> >         > hardly required in practice.
> >
> >
> >         Why not....for example... I want to print "quitting...." error
> >         msg if
> >         I get SIGINT or SIGQUIT.
>
> Call sigaction() two times ....
>
> > Ok. i think these messages are for debugging purpose. But anyway let
> >  it be common. :)
>
> That's the problem: It is not common. And if the set of signals is
> probably different for all these cases.
>
> What's the drawback of the current situation?
> It you you have the (IMHO) uncommon situation where you want to use the
> same signal handler for different signals, you can easily call
> sigaction() for all of them separately and be done. This is usually done
> one per application so there is no point in speeding it up.
>
> And just adding one system-call to cope with a rarely used operation
> which can easily be simulated with other existing ones is a waste of
> time for development and RAM on each host.
>

   is there any need of raise() system call if we have kill() system call
which  is capable of sending signals to the process itself? Actually there
are lots of examples of this type .Some of them are for compatibility
 reasons  and still some are "i dont know why." :)


> >         > But i think this type of system call should be
> >         > in Linux systems which can serve handler functionality on
> >         some of signals.
> >         > Please tell me the flaws proposing something like this. i
> >         want to work on
> >         > this tiny problem. :)
>
> What is the semantic of an error?
> At least one signal registration fails or all failed or some failed?
> well if we think in this way then there are some examples where failure of
> some critical system calls is handled by trying for them again and again.
> And what is the application expected to do if it actually failed (for
> whatever reason).
>
> But feel free to implement it and play around!
>
  But anyway thanks a lot  :)

>
> 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/20110319/e29e62b2/attachment.html 

Common signal handler system call

[Bernd Petrovitsch]

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.

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.

> 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

Common signal handler system call

[mohit verma]

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 

Common signal handler system call

[Javier Martinez Canillas]

On Sun, Mar 20, 2011 at 8:38 AM, mohit verma <mohit89mlnc@gmail.com> wrote:
>> 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).
>>

Hi Mohit,

A problem I see with your idea is that it is not POSIX-compliant.
Linux being a Unix-like operating system tries to adhere to the
standard as much as possible. Although is true that it is not tied to
the specification. Whenever a change has strong arguments (an more
important valid use cases) Linux can deviate from the standard.

But as Bernd says, taking to the kernel something that can be done in
users-pace with no real gain and also breaking POSIX signals semantics
is something that will be hard to merge into the kernel.

Also, to implement a syscall you have to convince not only the kernel
developers that this change makes sense but also propose a patch to
glibc to implement a function library that uses your new syscall.

Best regards,

-----------------------------------------
Javier Mart?nez Canillas
(+34) 682 39 81 69
PhD Student in High Performance Computing
Computer Architecture and Operating System Department (CAOS)
Universitat Aut?noma de Barcelona
Barcelona, Spain

Common signal handler system call

[Bernd Petrovitsch]

On Son, 2011-03-20 at 13:08 +0530, mohit verma wrote: [...] 
> I think it should be there in kernel not because it is my idea but for
> good reasons (personally think so). 

... and despite IMHO good reason for not including.
But talk is cheap so prepare and propose a working prototype as patch
and we will see the reaction from others.

I'm not strong against it but I do not see any significant advantage but
at least one open question and the burden to all which do not need/use
it[0].

ad "POSIX compliance": Well, there are lots of system calls (in the
Linux kernel) which are not in POSIX (or SuSv3 or ...) - plain simply
because they are newer than these "standards" or out of the scope of
them.
And (on Linux with and/or without GNU-libc) some system-calls (or
whatever POSIX calls them) are "only" libc functions which are
transformed into other, real existing system-calls.

Bernd

[0]: And that is partly due to my embedded background where you strive
     to make everything small and avoid bloat;-)
-- 
Bernd Petrovitsch                  Email : bernd at petrovitsch.priv.at
                     LUGA : http://www.luga.at

Common signal handler system call

[mohit verma]

On Mon, Mar 21, 2011 at 4:08 PM, Bernd Petrovitsch <
bernd@petrovitsch.priv.at> wrote:

> On Son, 2011-03-20 at 13:08 +0530, mohit verma wrote: [...]
> > I think it should be there in kernel not because it is my idea but for
> > good reasons (personally think so).
>
> ... and despite IMHO good reason for not including.
> But talk is cheap so prepare and propose a working prototype as patch
> and we will see the reaction from others.
>
>   thanks  a lot Bernd. I am gonna do it.

I'm not strong against it but I do not see any significant advantage but
> at least one open question and the burden to all which do not need/use
> it[0].
>
> ad "POSIX compliance": Well, there are lots of system calls (in the
> Linux kernel) which are not in POSIX (or SuSv3 or ...) - plain simply
> because they are newer than these "standards" or out of the scope of
> them.
> And (on Linux with and/or without GNU-libc) some system-calls (or
> whatever POSIX calls them) are "only" libc functions which are
> transformed into other, real existing system-calls.
>
> Bernd
>
> [0]: And that is partly due to my embedded background where you strive
>     to make everything small and avoid bloat;-)
> --
> 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/20110321/11bd9a26/attachment.html