Date: Fri, 05 Feb 2016 12:21:52 -0800 From: John Baldwin <jhb@freebsd.org> To: Jilles Tjoelker <jilles@stack.nl> Cc: arch@freebsd.org Subject: Re: Refactoring asynchronous I/O Message-ID: <9227739.EqUaAQ57pU@ralph.baldwin.cx> In-Reply-To: <20160131230214.GA37435@stack.nl> References: <2793494.0Z1kBV82mT@ralph.baldwin.cx> <20160131230214.GA37435@stack.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
On Monday, February 01, 2016 12:02:14 AM Jilles Tjoelker wrote: > On Tue, Jan 26, 2016 at 05:39:03PM -0800, John Baldwin wrote: > > Note that binding the AIO support to a new fileop does mean that the AIO code > > now becomes mandatory (rather than optional). We could perhaps make the > > system calls continue to be optional if people really need that, but the guts > > of the code will now need to always be in the kernel. > > Enabling this by default is OK with me as long as the easy ways to get a > stuck process are at least disabled by default. Currently, a process > gets stuck forever if it has an AIO request from or to a pipe that will > never complete. An AIO daemon should not be allowed to perform an > unbounded sleep such as for a pipe (NFS server should be OK). One thing I could do is split vfs_aio.c into two files: kern_aio.c that holds the "library" such as aio_aqueue() / aio_complete(), etc. and a sys_aio.c that is just the system calls. kern_aio.c would be standard, but sys_aio.c could still be optional and aio.ko would contain it. This would still make AIO optional, though aio.ko would be fairly small, so not having it probably wouldn't save much in terms of size. Does this seem reasonable or is a trivial aio.ko not worth it? -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9227739.EqUaAQ57pU>