[PATCH] fadvise(2) system call

[Garrett Cooper]

On Mon, Oct 31, 2011 at 2:17 PM, John Baldwin <jhb at freebsd.org> wrote:
> On Monday, October 31, 2011 3:03:59 pm Ed Schouten wrote:
>> Hi John,
>>
>> * John Baldwin <jhb at 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()?

int fadvise(...);

#ifdef _POSIX_SOURCE
#define posix_fadvise fadvise
#endif

Done :P?

posix_* IMO is a mistake that really should be controlled via the
_POSIX_SOURCE macro.

> </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.