Re: just curious

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

:>     or mmapping() it.  mmap()ing it would result in the data being shared,
:>     but with mmap() one can also make things copy-on-write (MAP_PRIVATE), and
:>     so forth.  We already have the VM object layering model in place in the
:>     kernel to make it all possible so it would not require any special effort.
:
:So you'll be able to use the normal UNIX system calls to access 
:arbitrary VM objects? So if I have a VM object that represents a buffer 
:in another user process, it'll just look like a file to me? What happens 
:if I overrun the end of the buffer, ENOSPC?
:
:That's got some amazingly cool possibilities.

    Yes.  Compare it against the Mach 'I'm going to map the data into your
    address space' model.  There will be some cases where having the kernel
    map the address space is more efficient (saving two system calls),
    but most of the time there is no need or reason to map the data and in
    those cases passing a descriptor is far more efficient.

    Not to mention the space abstraction... passing a descriptor allows you
    to abstract I/O operations of any size.  You could handle ten someones
    each trying to write a 2GB buffer to your userland VFS.  And people are
    always forgetting atomicy.  There is no expectation of atomicy with
    memory mappings but there is one for I/O operations like read() or write().

    Most typical VFS filesystems and DEV block devices only need to copy
    data into or out of backing store, they don't have to access it
    directly, so all we would need is a system call (/message) kinda like
    sendfile() which copies data between two descriptors, like this:

	copyfile(int sfd, int dfd, off_t soffset, off_t doffset, off_t bytes)

    This is, roughly, no more or less complex then what a filesystem or
    device already has to do.

    Not to say that we wouldn't eventually want to have some sort of 
    auto-mmaping feature, but doing that sort of feature as the base
    abstraction is a real mistake.

					-Matt
					Matthew Dillon 
					<dillon@xxxxxxxxxxxxx>