Re: sendfile(2) SF_NOPUSH flag proposal
From: Terry Lambert (tlambert2_at_mindspring.com)
Date: 05/28/03
- Previous message: Terry Lambert: "Re: sendfile(2) SF_NOPUSH flag proposal"
- In reply to: Igor Sysoev: "Re: sendfile(2) SF_NOPUSH flag proposal"
- Next in thread: Kelly Yancey: "Re: sendfile(2) SF_NOPUSH flag proposal"
- Reply: Kelly Yancey: "Re: sendfile(2) SF_NOPUSH flag proposal"
- Reply: Igor Sysoev: "Re: sendfile(2) SF_NOPUSH flag proposal"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Wed, 28 May 2003 09:12:34 -0700 To: Igor Sysoev <is@rambler-co.ru>
Igor Sysoev wrote:
> 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.
Are you using an academically good search engine, or are you
using a commercial one, like Google and Yahoo?
There are two projects on NetBSD, one is rather stale, but it's
on the NetBSD "Projects Page"; the other was done by a Japanese
researcher into zero copy, whi has suggested that his work be
used to implement a splice(2) call as well. The OpenBSD work
was done in the context of their zro-copy "zbuf" implementation,
as a proof of concept.
I suggest the search terms "sendfile" and "openbsd", or the
terms "sendfile", "netbsd", "splice". Even Google finds some
mailing list chatter about those (the interesting one is by
Jason Thorpe from Wasabi Systems, and is in Japanese).
> > 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.
And have any code that uses your new flags not compile for
lack of a definition of those flags in a header file.
> As well as FreeBSD's rfork() implementation ignores some plan9 flags.
FreeBSD's rfork() predates plan9. Sequent's rfork() predates
FreeBSD's.
> > Yes, the argument lists aren't the same. AIX and MVS both
> > have identical interfaces, though.
>
> But different with FreeBSD, right ?
FreeBSD is gratuitously different. You are planning on making
it *more* gratuitously different. That's probably a bad thing.
> > > 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().
Or... here's a thought... people would change the FreeBSD
implementation to comply with international standards, and
programmers would write only to the POSIX interface.
> > 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 ?
Here we get to the nub of things, then. You are being
obstinate not because you really want the flags, but
because you want someone else to do the actual work of
fixing sendfile for you.
There's probably no reason to continue this conversation,
unless you are going to insist on it. Five people have
told you the correct approach is to fix sendfile(2), and
you have ignored all of us. Three people, not all the same
people as before, have told you that if you could measure a
statistically significant performance improvement from your
proposed changes, we wouldn't object to your code going in,
even though it breaks source compatability further.
Other than writing the correct code for you, there's little
else we can do, and I, at least, have other code I need to
write, to solve my own problems.
-- Terry
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"
- Previous message: Terry Lambert: "Re: sendfile(2) SF_NOPUSH flag proposal"
- In reply to: Igor Sysoev: "Re: sendfile(2) SF_NOPUSH flag proposal"
- Next in thread: Kelly Yancey: "Re: sendfile(2) SF_NOPUSH flag proposal"
- Reply: Kelly Yancey: "Re: sendfile(2) SF_NOPUSH flag proposal"
- Reply: Igor Sysoev: "Re: sendfile(2) SF_NOPUSH flag proposal"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
|
