aboutsummaryrefslogtreecommitdiffstats
path: root/include/linux/signal.h (follow)
AgeCommit message (Collapse)AuthorFilesLines
2005-05-01[PATCH] new valid_signal() functionJesper Juhl1-0/+6
This patch adds a new function valid_signal() that tests if its argument is a valid signal number. The reasons for adding this new function are: - some code currently testing _NSIG directly has off-by-one errors. Using this function instead avoids such errors. - some code currently tests unsigned signal numbers for <0 which is pointless and generates warnings when building with gcc -W. Using this function instead avoids such warnings. I considered various places to add this function but eventually settled on include/linux/signal.h as the most logical place for it. If there's some reason this is a bad choice then please let me know (hints as to a better location are then welcome of course). Signed-off-by: Jesper Juhl <juhl-lkml@dif.dk> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-05-01[PATCH] move SA_xxx defines to linux/signal.hStas Sergeev1-0/+11
The attached patch moves the IRQ-related SA_xxx flags (namely, SA_PROBE, SA_SAMPLE_RANDOM and SA_SHIRQ) from all the arch-specific headers to linux/signal.h. This looks like a left-over after the irq-handling code was consolidated. The code was moved to kernel/irq/*, but the flags are still left per-arch. Right now, adding a new IRQ flag to the arch-specific header, like this patch does: http://cvs.sourceforge.net/viewcvs.py/*checkout*/alsa/alsa-driver/utils/patches/pcsp-kernel-2.6.10-03.diff?rev=1.1 no longer works, it breaks the compilation for all other arches, unless you add that flag to all the other arch-specific headers too. So I think such a clean-up makes sense. Signed-off-by: Stas Sergeev <stsp@aknet.ru> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-16Linux-2.6.12-rc2Linus Torvalds1-0/+224
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!