sendfile(2) SF_NOPUSH flag proposal

[Igor Sysoev]

On Wed, 28 May 2003, Terry Lambert wrote:

> Igor Sysoev wrote:
> > Really ?  I think that on NetBSD, Darwin, and MacOS X I would get:
> > -----
> > warning: implicit declaration of function `sendfile'
> 
> I think on NetBSD and OpenBSD, a single search-engine query
> would show you three experimental implementations, all of
> which have the FreeBSD syntax.

I did not found any.

> The Darwin/MacOS X is a no-brainer: someone will get around
> to it eventually; the big barrier is external mbufs, and
> those are really trivial to implement (IMO; I've done it on
> three separate occasions in different code bases, now).

If someone will eventually implement on NetBSD, OpenBSD or Darwin/MacOS X
the FreeBSD compatible sendfile() then he can simply ignore any unsupported
flags.  As well as FreeBSD's rfork() implementation ignores some plan9 flags.

> > On Solaris and Linux I will get:
> > -----
> > too many arguments to function `sendfile'
> 
> Yes, the argument lists aren't the same.  AIX and MVS both
> have identical interfaces, though.

But different with FreeBSD, right ?
It was be very strange if IBM made different send_file() interfaces
for its own systems.

> > sendfile() is very and very unportable interface.
> 
> I have no doubt that sendfile(2) will eventually be standardized
> by some well-intentioned standards body, and that the standard
> will not include implementation-bug-based flags definitions.

So what ?  Developer would wrote yet more #define or wrapper for
POSIX sendfile().

> > And #define can hide any flags.
> 
> Code written that way is not portable, it has been ported.
> There is a big difference.

Well, but it's the same thing I told you.  If developer want to use
sendfile() he should be ready that he needs to port its source.
He can make easy port with #define or harder port with wrapper.

> Why are you so dead-set on adding crufty flags, when three
> people who have been in that code before (I back-ported the
> external mbuf code and sendfile to FreeBSD 4.2 and 4.3 at
> one point; Matt has lived in that code; Peter had his nose
> in for quite a while; etc.) say that it's broken, and the
> correct thing to do is to fix it, not add a bunch of kludge
> code to work around the bugs that shouldn't be there in the
> first place?

Well, how do your code handle the partially filled file packets ?


Igor Sysoev
http://sysoev.ru/en/