:
:Great. Then we have aliased file pointers...
:that's not a great improvement..
:
:You'd still have to have 'per instance' storage somewhere,
:so that the openned devices could have different permissions, and still
:have them point to common data. so you still need
:aliases, except now it's not a vnode being aliased but some
:other structure.
VNodes should never have been aliased in the first place, IMHO. We
have to deal with certain special cases, like mmap'ing /dev/zero,
but that is a minor issue I think.
Actually, all this talk does imply that VM objects should be independant
of vnodes. Devices may need to mmap (requiring a VM object), but
don't need all the baggage of a vnode. Julian is absolutely correct
there.
We do need to guarentee locking order, which means that all I/O
operations should be consistent. If a device or vnode is mmap()able,
then all read, write, and truncation(/extention) ops *should* run
through the VM object first:
read/write/truncate fileops -> [VM object] -> device
read/write/truncate fileops -> [VM object] -> vnode
Relative to Poul's last message, this would require not only adding
MMAP to the fileops, but also adding FTRUNCATE to the fileops. Not
a big deal!
If a device or file is not mmap()able, then the VM object would not
exist. You wouldn't get any caching, either, in that case, unless the
device implemented the caching natively.
If a device or file can be mmap()'d, then the VM Object acts as the
cache layer for the object. We would in fact be able to remove nearly
*ALL* the caching crap from *ALL* the filesystem code. Filesystem
code would be responsible for low level I/O operations and meta ops
(VOPs) only and not be responsible for any caching of file data. The
filesystem would still potentially be responsible for caching things
like bitmaps and such, but it could use a struct file for the backing
device and get it for free (the backing device is mmapable and thus
would have a VM Object layer, so you get the bitmap caching for free).
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
