2017-10-06 16 views
-1

私はSIGUSR1とSIGUSR2(または他の標準シグナル)とは別に独自のカスタム名前付きシグナルを定義したいと思います。 これについてはどうすればよいですか?Linuxカーネルで独自のカスタムシグナルを作成する

+0

それは本当に難しいです、それは基本的に不可能です。既に32のシグナルがあり、32ビットの 'int'の個々のビットに対応しなければならないように見えます。私が1つ追加したとき、私は既存のものを奪う必要がありました。しかし、私が追加を始めたところでは、それは 'arch/arm/include/asm/signal.h'にありました(私はARMで作業していたので、' arch/x86/... 'かもしれません)。カーネル内部から私は 'internal_kill()'を呼び出して私のシグナルをユーザプロセスに送り出しました。 –

+0

カスタム名でシグナルの1つを再定義しようとしましたが、ユーザーのアプリケーションからシグナルを呼び出すときに信号を認識しません。私はARMで作業しています。 – RubberDuck

+0

一方、カーネルソースディレクトリ内のシグナル名を定義するヘッダファイルは、通常のユーザモードのCファイルがコンパイル時に参照するヘッダファイルとは異なる場合があります。ヘッダーファイルの2つの別々のインスタンスを手動で同期させておく必要があります。 –

答えて

1

http://man7.org/linux/man-pages/man7/signal.7.htmlは、real time signalsを定義できますが、定義済みの意味はありません。追加するものはほとんどありません

The range of supported real-time signals 
    is defined by the macros SIGRTMIN and SIGRTMAX. POSIX.1-2001 
    requires that an implementation support at least _POSIX_RTSIG_MAX (8) 
    real-time signals. 

    The Linux kernel supports a range of 33 different real-time signals, 
    numbered 32 to 64. However, the glibc POSIX threads implementation 
    internally uses two (for NPTL) or three (for LinuxThreads) real-time 
    signals (see pthreads(7)), and adjusts the value of SIGRTMIN suitably 
    (to 34 or 35). Because the range of available real-time signals 
    varies according to the glibc threading implementation (and this 
    variation can occur at run time according to the available kernel and 
    glibc), and indeed the range of real-time signals varies across UNIX 
    systems, programs should never refer to real-time signals using hard- 
    coded numbers, but instead should always refer to real-time signals 
    using the notation SIGRTMIN+n, and include suitable (run-time) checks 
    that SIGRTMIN+n does not exceed SIGRTMAX. 

SIGRTMIN+n < SIGRTMAXSIGRTMIN+nを使用しています。コンパイル時のチェックを行います(つまり、libcの実装よりも多くの信号が必要な場合は問題になります)。

何かのようなものがある#define SIGRUBBERDUCK (SIGRTMIN+3)

+0

はい、これは私がやったことです、それは働いた...ありがとう! – RubberDuck

関連する問題