Date: Sun, 12 Sep 2004 23:25:13 +0200 From: "Poul-Henning Kamp" <phk@phk.freebsd.dk> To: "M. Warner Losh" <imp@bsdimp.com> Cc: arch@freebsd.org Subject: Re: [BIKESHED] Giving abort(2) a reason Message-ID: <61286.1095024313@critter.freebsd.dk> In-Reply-To: Your message of "Sun, 12 Sep 2004 15:20:47 MDT." <20040912.152047.16265436.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <20040912.152047.16265436.imp@bsdimp.com>, "M. Warner Losh" writes: >In message: <61109.1095023635@critter.freebsd.dk> > "Poul-Henning Kamp" <phk@phk.freebsd.dk> writes: >: In message <20040912.142552.83283958.imp@bsdimp.com>, "M. Warner Losh" writes: >: >: >: 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? >: >: Well, the problem is that practically nothing else works once malloc >: fails, and people seem to find the lack of visible explanation a >: problem. >: >: syslog() or anything else using varargs is not going to work... > >Wouldn't it be better to have a more generic 'Put this into dmesg' >thing that doesn't require malloc to work? It seems silly to bloat >the kernel for only a malloc failure case... That is what I thought I proposed... -- 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?61286.1095024313>