From owner-cvs-src@FreeBSD.ORG Mon Feb 16 11:03:00 2004 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0403F16A4D1 for ; Mon, 16 Feb 2004 11:03:00 -0800 (PST) Received: from smtp.mho.com (smtp.mho.net [64.58.4.5]) by mx1.FreeBSD.org (Postfix) with SMTP id BFB8043D2F for ; Mon, 16 Feb 2004 11:02:59 -0800 (PST) (envelope-from scottl@freebsd.org) Received: (qmail 49956 invoked by uid 1002); 16 Feb 2004 19:02:57 -0000 Received: from unknown (HELO ?10.4.1.17?) (64.58.1.252) by smtp.mho.net with SMTP; 16 Feb 2004 19:02:57 -0000 Date: Mon, 16 Feb 2004 12:03:45 -0700 (MST) From: Scott Long X-X-Sender: scottl@pooker.samsco.home To: Robert Watson In-Reply-To: Message-ID: <20040216120153.S80753@pooker.samsco.home> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: cvs-src@FreeBSD.org cc: src-committers@FreeBSD.org cc: cvs-all@FreeBSD.org cc: Dag-Erling Smorgrav Subject: Re: cvs commit: src/sys/vm vm_kern.c X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2004 19:03:00 -0000 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. Scott