From owner-cvs-all Sun Dec 29 15:45:43 2002 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 6BAEA37B401; Sun, 29 Dec 2002 15:45:42 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id D735543ED8; Sun, 29 Dec 2002 15:45:41 -0800 (PST) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.12.6/8.12.5) with SMTP id gBTNjg1Z000604; Sun, 29 Dec 2002 18:45:42 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Sun, 29 Dec 2002 18:45:42 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Garrett Wollman Cc: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/kern syscalls.master In-Reply-To: <200212292217.gBTMHLpV009761@khavrinen.lcs.mit.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, 29 Dec 2002, Garrett Wollman wrote: > > These calls are similar in spirit to lstat(), lchown(), lchmod(), etc, > > ...except for the extreme verbosity in their names. Yeah. They're derived from the POSIX1e-D17 naming scheme, and that naming scheme sucks. :-) > There should probably be a file mode bit that is returned by stat() to > indicate that additional attributes exist that are not in struct stat. When I first did the ACL stuff, I noticed the ls(1) extension described in the draft spec and implemented on a number of platforms, which essentially prints a '+' after the ls -l mode display if there are extended protections. At that point, we didn't have any obviously spare and appropriate bits in struct stat. If/when we upgrade all these structures for 64-bit extensions, we should be sure to look at this. I'm not sure we want to generally signify the presence of extended attributes -- probably just the ones with recognizably useful semantics. With UFS2, we added more flag bits to the inode, with the intent of using some of the spare bits to cache extended attribute information so we could avoid reading in extended attributes unnecessarily. For example, adding a flag indicating whether an access ACL or a default ACL is present would allow us to avoid reading in those EAs during ufs_access(). For soft updates reasons, they'd be hints with appropriate failure modes (if the hint is wrong, it indicates the EA is present rather than not). Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Network Associates Laboratories To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message