DragonFly kernel List (threaded) for 2004-05
Re: (userspace) vfs and xio
:Matt and others,
:first some basic Q:
:can a xio_t be used in userland (as it can hold userspace data),
:can a process (possibly with root credentials) read or write to xio_t pages
:of another process? if not (i assume so), is there a possibility to allow
:that (maybe as fbufs  or to mmap)?
No, it can't be used in userland. XIO's are only designed to hold pages
temporarily and basically go directly to a physical memory address,
which is outside the userland abstraction.
:now to the vfs:
:Matt, you plan(ned) to convert most io w/ uio to xio. does that include vfs?
:i think so, but it does collide with your vfs model plans  ("The VOP
:interface will NOT handle direct userspace addresses any more"). i guess
:the xio abstraction is enough, but maybe you still think, pages should be
:copied to kvm before...
:will the new vop api be similar to the old one (except uio stuff of course)?
:and finally, may there be filesystem processes (fileservers as in plan9),
:that have no root-euid, i hope so :)
UIO's are going to stick around a lot longer, but the idea is for the
I/O operations to devolve down into XIO 'chunks'. XIO's are going to
go into the buffer cache (since there is almost a 1:1 correspondance)
before they go into VFS.
The issue with userspace UIO's in VFS is two fold: First, the VFS
operation may involve a thread switch and the cross-address-space data
access that standard UIO would otherwise have to do is extremely
expensive. the XIO cannot lock up too many pages at once so they are
limited to smaller (e.g. 128KB or 256KB) chunks whereas UIO's can
cover megabytes or gigabytes in a single I/O without wiring down all
those pages. So you can't directly convert a UIO to a (single) XIO.
But because cross-address-space access are so expensive, it will
probably be more efficient to break a large UIO into an XIO loop
and take the thread switching hit in the loop rather then to try to pull
out a portion of a foreign address space. Besides, physical I/O
is already limited to 128KB/256KB chunks so the extra thread switches
will not be that big an issue.