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>