Date: Wed, 27 Nov 2013 11:36:44 -0800 From: Adrian Chadd <adrian@freebsd.org> To: "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org>, freebsd-current <freebsd-current@freebsd.org>, Konstantin Belousov <kib@freebsd.org>, Gleb Smirnoff <glebius@freebsd.org> Subject: [review] sendfile / sendfile_sync refactoring Message-ID: <CAJ-VmomGd_-v7caBV1GxHhOAXG9Mgb3dVPh7vqAbZQWY3iiOYA@mail.gmail.com>
next in thread | raw e-mail | index | archive | help
Hi, Here's part #2 in my sendfile refactoring. This is a little more intrusive than the first patch. http://people.freebsd.org/~adrian/netflix/20131126-sendfile-sync-refactor-2.diff My aim here is to move the sendfile_sync stuff out of uipc_syscalls.c and out of sendfile-only code and into something that can be reused elsewhere or replaced later on. I've created methods for all the sendfile_sync stuff, I've moved it out of the do_sendfile() loop so do_sendfile() doesn't specifically implement the completion behaviour. Initially, I'm going to implement a sendfile knote representing the completion of this particular mbuf transaction. I also have a vague, handwav-y idea to use this kind of mbuf transaction representation for later work with aio_write() (and maybe an aio_writev()) when writing to a socket - wire in the userland memory, create a chain of mbufs to represent those, wrap them up in a sendfile_sync (or whatever it mutates into) and then use that for the kqueue completion notification. It needs the same kind of mbuf transaction and kqueue notification mechanism so I'd like to eventually make the sendfile_sync stuff generic, or use the memory buffer representation from jhb, to implement this in a variety of places. I'm not entirely happy where the sendfile_sync stuff is living but this is all meant to be transition-y and enable further hacking on sendfile / variations thereof without having to duplicate too much code. Thanks, -adrian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-VmomGd_-v7caBV1GxHhOAXG9Mgb3dVPh7vqAbZQWY3iiOYA>