From owner-cvs-all@FreeBSD.ORG Sat Apr 22 12:45:37 2006 Return-Path: X-Original-To: cvs-all@FreeBSD.org 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 6278616A402; Sat, 22 Apr 2006 12:45:37 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0672D43D45; Sat, 22 Apr 2006 12:45:37 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id B7C4746C2F; Sat, 22 Apr 2006 08:45:35 -0400 (EDT) Date: Sat, 22 Apr 2006 13:45:35 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Tom Rhodes In-Reply-To: <20060422001635.247a8b88.trhodes@FreeBSD.org> Message-ID: <20060422133933.A56433@fledge.watson.org> References: <200604210714.k3L7EQhD046878@repoman.freebsd.org> <20060421161321.J44089@fledge.watson.org> <20060421212322.2f5b3fa8.trhodes@FreeBSD.org> <1A949C80-E65D-4349-8028-8B0EB1A91D27@FreeBSD.org> <20060422001635.247a8b88.trhodes@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org, cvs-all@FreeBSD.org, John Baldwin Subject: Re: cvs commit: src/sys/ufs/ffs ffs_vfsops.c X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.5 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: Sat, 22 Apr 2006 12:45:37 -0000 On Sat, 22 Apr 2006, Tom Rhodes wrote: > Which is why I suggested that, similar to Linux, we make everything an > option instead of either Warning before you build/install the new kernel or > add the addition headache of turning it on later. Thus, I'm still of the > opinion that one does not blindly add a newfs option during the install > without understanding what's going on. The problem you're diagnosing is booting a kernel that doesn't support features requested by the administrator. When this happens, there are really only two things you can do: (1) Generate warnings and continue. (2) Generate warnings and stop. We opt for (1) because it makes recovery easier. Deleting the warnings helps neither case. Booting an SELinux system without an SELinux kernel will fail in many spectacular ways, but I'm not sure if they generate a warning equivilent to the one you deleted. BTW, turning on the multilabel flag in sysinstall is not an option offered by the installer -- by setting it using sysinstall's "additional flags" field, you're specifially doing something not part of the install path. The MAC instructions I've provided always involve completing the normal install, building MAC support, etc, not turning it on in sysinstall and expecting it to work. The only instructions I've distributed that involve setting multilabel in sysinstall relate to the SEBSD install ISOs, which explicitly support flagging multilabel support during the install. >>> I'll revert it if you feel strongly about it; however, I want it >>> to be known what my opinion is. And I find the warnings >>> extremely annoying and have answered at least one question as >>> to why "mount don't show me correct output." Yes, real quote. :) >> >> mount != tunefs. tunefs will tell you what options are enabled in the > > Yes. > >> filesystem, but I think mount should only tell you the options that are >> actually in force. > > Once they're enabled does that not mean they are in force? I'm not sure what you mean by "enabled" here. Flags only have an effect if the kernel code to support them is compiled in. The way the code was before you modified it, the flags could not be shown in mount if the kernel didn't implement them -- i.e., if you type in "mount" and don't see ACLs, then they are not implemented, and if you do see ACLs, then they are implemented. With your change, they can now be set but not implemented. I.e., you can look at mount, see "acls" set, but ACLs won't actually be in force, which I consider a more confusing failure mode. If you mean, can they be enabled in tunefs but not in force -- yes, if you are running a kernel that can't support them. In which case, before your change, a warning was generated, but not now. Robert N M Watson