Date: Fri, 23 Apr 2004 00:25:34 -0400 (EDT) From: Robert Watson <rwatson@FreeBSD.org> To: Thomas Moestl <t.moestl@tu-bs.de> Cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/kern vfs_syscalls.c Message-ID: <Pine.NEB.3.96L.1040423002410.40676A-100000@fledge.watson.org> In-Reply-To: <20040422231910.GB709@timesink.dyndns.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 23 Apr 2004, Thomas Moestl wrote: > Hmmm, I'm not sure, but wasn't the real bug to use the struct mount * > that vn_start_write() returns instead of nd.ni_vp->v_mount (or at least, > not using nd.ni_vp->v_mount if mp turns out to be NULL)? extattrctl() > chooses that way. It seems that file systems are not required to > implement VOP_GETWRITEMOUNT(), but could choose to implement > VFS_QUOTACTL() anyway (although IIRC there currently are none that > maintain this combination), so unconditionally returning EOPNOTSUPP > would be too strict. > > The only case where the mount point of the vnode and the mount point > returned by vn_start_write() should differ is when unionfs is involved; > in that case, the correct semantics of quotactl() is a bit doubtful, and > so unionfs does not support quotactl() at all; thus using the mount > point of the vnode should not break anything. FWIW, in Darwin, Apple has moved the majority of ufs_quota.c to a vfs_quota.c, which acts as a library of quota-related functions serving both UFS and HFS+. It's not impossible to imagine a similar arrangement in FreeBSD should we import HFS+ into the base system, or for other file systems as it proves necessary. A bit of cleanup is required to make the utility functions accept explicit ID arguments instead of inode pointers, etc, but it would be fairly straight forward. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Senior Research Scientist, McAfee Research
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1040423002410.40676A-100000>