DragonFly kernel List (threaded) for 2003-07
Re: just curious
:> 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.