Date: Sun, 5 Sep 2004 14:46:32 -0500 From: Alan Cox <alc@cs.rice.edu> To: Peter Pentchev <roam@FreeBSD.ORG>, src-committers@FreeBSD.ORG, cvs-src@FreeBSD.ORG, cvs-all@FreeBSD.ORG Subject: Re: cvs commit: src/lib/libc/sys msync.2 Message-ID: <20040905194632.GK10220@cs.rice.edu> In-Reply-To: <20040905013043.GA29649@VARK.homeunix.com> References: <200409030624.i836OPaL018916@repoman.freebsd.org> <20040905013043.GA29649@VARK.homeunix.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Sep 04, 2004 at 09:30:43PM -0400, David Schultz wrote: > On Fri, Sep 03, 2004, Peter Pentchev wrote: > > roam 2004-09-03 06:24:25 UTC > > > > FreeBSD src repository (doc,ports committer) > > > > Modified files: > > lib/libc/sys msync.2 > > Log: > > Add a BUGS section and copy the wording from mmap(2)'s MAP_NOSYNC, > > documenting the obsoleteness of the msync(2) syscall and its single > > remaining purpose. > > I'm not nitpicking at you since you didn't write the original > text, but if msync(2) still has a purpose, then it isn't really > obsolete, is it? (Moreover, the text only describes the purpose of > msync(2) with the MS_ASYNC flag.) Applications such as databases > that want greater control over the flushing of dirty data may > still find msync(2) very useful. I agree. This sentence should be removed from both msync.2 and mmap.2 for precisely the reason you state. It is, however, worth mentioning that FreeBSD has a unified buffer and virtual memory page cache in these man pages. In fact, that does make most uses of msync()'s MS_INVALIDATE flag unnecessary. (The useful cases being things like the extension used by the Nvidia driver.) On a related note, where do we stand with respect to the use of X/Open man pages? The X/Open man page for msync(2) is much better than ours. Alan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040905194632.GK10220>