To: linux-kernel@vger.kernel.org
From: "H. Peter Anvin" <hpa@zytor.com>
Subject: Re: x86: SIGTRAP handling differences from 2.4 to 2.6
Date: 22 Nov 2003 22:21:17 -0800
Organization: Transmeta Corporation, Santa Clara CA
Message-ID: <bppjkt$ik0$1@cesium.transmeta.com>
References: <16319.57610.204577.206796@cargo.ozlabs.ibm.com> <Pine.LNX.4.44.0311221435090.2379-100000@home.osdl.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7BIT
Disclaimer: Not speaking for Transmeta in any way, shape, or form.
Copyright: Copyright 2003 H. Peter Anvin - All Rights Reserved
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1390
Lines: 33

Followup to:  <Pine.LNX.4.44.0311221435090.2379-100000@home.osdl.org>
By author:    Linus Torvalds <torvalds@osdl.org>
In newsgroup: linux.dev.kernel
> 
> Hmm.. Looking at the signal sending code, we actually do special-case 
> "init" there already - but only for the "kill -1" case. If the test for 
> "pid > 1" was moved into "group_send_sig_info()" instead, that would 
> pretty much do it, I think.
> 

Okay... I'm going to ask the obvious dumb question:

Why do we bother special-casing init at all?

It seems the only things init can't ask the kernel to do already for
it is to block SIGSTOP and SIGKILL, and it seems that if you killed
(or stopped?) init you should just get the kernel panic.

If there is anything that should be special-cased, then perhaps it
should be that init should be allowed to block/catch/ignore
SIGSTOP/SIGKILL.  Perhaps that should be a capability?

	-hpa
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
If you send me mail in HTML format I will assume it's spam.
"Unix gives you enough rope to shoot yourself in the foot."
Architectures needed: ia64 m68k mips64 ppc ppc64 s390 s390x sh v850 x86-64
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/