[PATCH] fadvise(2) system call

[John Baldwin]

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()?

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