From owner-freebsd-arch@FreeBSD.ORG  Wed Sep  8 08:30:49 2004
Return-Path: <owner-freebsd-arch@FreeBSD.ORG>
Delivered-To: freebsd-arch@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 511AD16A4CE
	for <arch@freebsd.org>; Wed,  8 Sep 2004 08:30:49 +0000 (GMT)
Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163])
	by mx1.FreeBSD.org (Postfix) with ESMTP id B3C6943D1D
	for <arch@freebsd.org>; Wed,  8 Sep 2004 08:30:48 +0000 (GMT)
	(envelope-from phk@critter.freebsd.dk)
Received: from critter.freebsd.dk (localhost [127.0.0.1])
	by critter.freebsd.dk (8.13.1/8.13.1) with ESMTP id i888UkGN036514
	for <arch@freebsd.org>; Wed, 8 Sep 2004 10:30:47 +0200 (CEST)
	(envelope-from phk@critter.freebsd.dk)
To: arch@freebsd.org
From: Poul-Henning Kamp <phk@phk.freebsd.dk>
Date: Wed, 08 Sep 2004 10:30:46 +0200
Message-ID: <36513.1094632246@critter.freebsd.dk>
Sender: phk@critter.freebsd.dk
Subject: [BIKESHED]  Giving abort(2) a reason
X-BeenThere: freebsd-arch@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Discussion related to FreeBSD architecture
	<freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
	<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
	<mailto:freebsd-arch-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 08 Sep 2004 08:30:49 -0000


A brief talk about malloc's 'A' option on that channel raised again the
idea that we should have a variant of abort(2) which takes a reason
which will be logged in the syslog buffers so people can see what is
wrong rather than just get a core dump.

Given that we are usually pretty stumped when we get to call abort(2)
it needs to work without malloc or anything like it and varargs into
the kernel is not at all in my future.

My proposal therefore is a system call something like:

	abort2(const char *why, int nargs, void **args);

this would terminate the process like abort(2) and in addition produce
a message in the syslog buffer along these lines:

   Aborted $procname pid $pid uid $uid gid $gid.
   Aborted $procname pid $pid $why $arg1 $arg2...

A typical usage would be:

	if (speed > mach1) {
		void *msg[2];

		msg[0] = speed;
		msg[1] = mach1;

		abort2("Supersonic speed not supported", 2, msg);
	}

and the output in syslog would be:

    Aborted sophwith pid 23 uid 100 gid 100.
    Aborted sophwith pid 23 Supersonic speed not supported 0x4dd 0x3aa

Is this workable ?

Anyone want to try their hands at an implementation ?


-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.