Date: Mon, 31 Oct 2011 17:17:53 -0400 From: John Baldwin <jhb@freebsd.org> To: Ed Schouten <ed@80386.nl> Cc: arch@freebsd.org, Jilles Tjoelker <jilles@stack.nl> Subject: Re: [PATCH] fadvise(2) system call Message-ID: <201110311717.53476.jhb@freebsd.org> In-Reply-To: <20111031190359.GP2258@hoeg.nl> References: <201110281426.00013.jhb@freebsd.org> <201110311024.07580.jhb@freebsd.org> <20111031190359.GP2258@hoeg.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
On Monday, October 31, 2011 3:03:59 pm Ed Schouten wrote: > Hi John, > > * John Baldwin <jhb@freebsd.org>, 20111031 15:24: > > Existing applications use the name and I find it ugly. (I also wish we > > had a plain fallocate() instead of just posix_fallocate().) However, if > > other folks prefer not having the wrapper I could update it to use the > > posix_* name. > > I agree with Jilles. It's easier to introduce namespace pollution than > it is to get rid of it afterwards. If the function is called > posix_fadvise(), people should just use that. They don't. They use fadvise() which is part of Linux's API much as madvise(2) is part of ours. (See the other fork in this thread.) > People are constantly complaining about `Linuxisms' when they want to > port software to FreeBSD. The word `BSDism' should remain an euphemism. > ;-) I think kqueue() is a useful BSDism. I think the attitude that we should have nothing that deviates from an established standard would be harmful if it was actually applied. I also really do think that posix_*() truly is far uglier to read. In the worst case, imagine something like this: char *cp; cp = posix_malloc(posix_strlen(some_string) + 1); posix_strcpy(cp, s); posix_printf("%s\n", cp); *blech* I realize not all symbols will get this treatment, but this will eventually lead to some ugly code the more it is done. I am fine with fully POSIX- compliant code looking ugly, but I'd like for code written for FreeBSD to not be quite so clunky. Yes, POSIX wants to use a clean namespace for new routines going forward, that's fine. However, I think we should provide sane names for our APIs and implement POSIX on top of those. How many folks have actually used posix_madvise() instead of madvise()? And do you really think posix_fadvise() as a function name is not less orthogonal to madvise() than fadvise()? </soapbox> That said, I can update the patch to use the ugly name. Can someone else volunteer to implement a VOP_ADVISE() for UFS that actually does the read- ahead (for FADV_WILLNEED) (or for other filesystems for that matter). ZFS might need to use a custom FADV_DONTNEED as well. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201110311717.53476.jhb>