Date: Mon, 16 Feb 2004 14:23:12 -0700 (MST) From: "M. Warner Losh" <imp@bsdimp.com> To: scottl@FreeBSD.org Cc: des@FreeBSD.org Subject: Re: cvs commit: src/sys/vm vm_kern.c Message-ID: <20040216.142312.76327813.imp@bsdimp.com> In-Reply-To: <20040216120153.S80753@pooker.samsco.home> References: <Pine.NEB.3.96L.1040216135731.63057M-100000@fledge.watson.org> <20040216120153.S80753@pooker.samsco.home>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <20040216120153.S80753@pooker.samsco.home>
Scott Long <scottl@FreeBSD.org> writes:
: On Mon, 16 Feb 2004, Robert Watson wrote:
: >
: > On Mon, 16 Feb 2004, Dag-Erling Smorgrav wrote:
: >
: > > Log:
: > > Don't panic if we fail to satisfy an M_WAITOK request; return 0 instead.
: > > The calling code will either handle that gracefully or cause a page fault.
: >
: > Also, this turns an easily understood and widely documented kernel panic
: > message into a page fault. Prior to this, users could google for the
: > message and find documentation on increasing the size of the kernel
: > address space. Now, it requires facility with the source code in order to
: > figure out what it is going on (since the page fault trace won't include
: > the memory allocation).
: >
:
: Agreed on all points. I thought that there was along discussion on this
: in the last 1-2 weeks and that all of these issues were brought up.
: Please back this out, and lets focus on getting the sematics that you need
: for procfs rather than just ruining the sematics for everything else.
Please back this out. We worked for a long time to make M_WAITOK mean
that the return value is never null.
Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040216.142312.76327813.imp>