From owner-freebsd-arch@FreeBSD.ORG Sun Sep 12 20:27:30 2004 Return-Path: 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 2E0A616A4CE for ; Sun, 12 Sep 2004 20:27:30 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5B01543D48 for ; Sun, 12 Sep 2004 20:27:29 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.13.1/8.13.1) with ESMTP id i8CKPGFS016427; Sun, 12 Sep 2004 14:25:16 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sun, 12 Sep 2004 14:25:52 -0600 (MDT) Message-Id: <20040912.142552.83283958.imp@bsdimp.com> To: phk@phk.freebsd.dk From: "M. Warner Losh" In-Reply-To: <36513.1094632246@critter.freebsd.dk> References: <36513.1094632246@critter.freebsd.dk> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: arch@freebsd.org Subject: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Sep 2004 20:27:30 -0000 In message: <36513.1094632246@critter.freebsd.dk> Poul-Henning Kamp writes: : : 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. Only in malloc. Everywhere else, people have enough state to cope. Do we really want to have another kernel API just to support malloc failures? : 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 ? That's really ugly. abort2(const char *fmt, ...) would be a much better user interface. Your interface really sucks from a programming point of view. If the only goal is to have the output in syslog, then use syslog directly on the args. No kernel APIs are needed: void abort2(const char *fmt, ...) { va_list args; syslog(LOG_ERR, "Aborted %s pid %d uid %d gid %d\n", __progname, getpid(), getuid(), getgid()); va_start(ap, fmt); vsyslog(LOG_ERR, fmt, ap); abort(); } The work to build the array is likely of similar complexity to the work needed to build the buffers above. The connection to syslog is more complex, I'll grant, but on the whole 99+% of the potential users of this API would have enough context/state remaining in the program to be able to do so. Wanrer