From owner-cvs-all@FreeBSD.ORG Tue Nov 30 14:41:59 2004 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B1BE016A4CE; Tue, 30 Nov 2004 14:41:59 +0000 (GMT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3394543D31; Tue, 30 Nov 2004 14:41:59 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.13.1/8.13.1) with ESMTP id iAUEdqEW046864; Tue, 30 Nov 2004 09:39:52 -0500 (EST) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)iAUEdqEI046861; Tue, 30 Nov 2004 14:39:52 GMT (envelope-from robert@fledge.watson.org) Date: Tue, 30 Nov 2004 14:39:52 +0000 (GMT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Doug Barton In-Reply-To: <41AC489E.7050108@DougBarton.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: cvs-src@FreeBSD.org cc: src-committers@FreeBSD.org cc: Ruslan Ermilov cc: phk@FreeBSD.org cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sbin/mount mntopts.h mount.8 mount.c src/sbin/mount_std mount_std.8 X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Nov 2004 14:41:59 -0000 On Tue, 30 Nov 2004, Doug Barton wrote: > >>FYI, this commit seems to have broken my line in fstab which has worked for > >>a long time: > >> > >>md /tmp mfs rw,-s16m,noatime,nosuid,nodev 2 0 > >> > >>Is it useful for the nodev option to cause a hard failure here? Note, I'm > >>not arguing against either change, just pointing out a side effect. > > > > There's no longer a "nodev" option, please ask Poul-Henning for details. ;) > > Yes, I understand the mechanics, I'm just curious if you think that this > should result in a fatal error. It sounds like you think that the answer > to that is yes, which if that is the correct answer I'm fine with that. I think a reasonable alternative would be for use of the nodev option to silently no-op in all cases but (perhaps) devfs, since the behavior described for nodev is in fact now simply the way the system behaves. Maybe the middle ground is to print a warning? Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Principal Research Scientist, McAfee Research