Re: (userspace) vfs and xio

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

: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 [1] 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 [2] ("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 :)
:
:~ibotty

    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.

					-Matt
					<dillon@xxxxxxxxxxxxx>