Date: Wed, 18 Apr 2001 11:42:09 -0700 (PDT) From: Matt Dillon <dillon@earth.backplane.com> To: Robert Watson <rwatson@FreeBSD.ORG> Cc: Julian Elischer <julian@elischer.org>, Poul-Henning Kamp <phk@critter.freebsd.dk>, Kirk McKusick <mckusick@mckusick.com>, Rik van Riel <riel@conectiva.com.br>, freebsd-hackers@FreeBSD.ORG, David Xu <bsddiy@21cn.com> Subject: Re: vm balance Message-ID: <200104181842.f3IIg9D38399@earth.backplane.com> References: <Pine.NEB.3.96L.1010418141424.2462O-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
:Does this give you a cache coherence problem if the file system itself
:invokes data writes on files? Consider the UFS quota and extended
:attribute cases: here, the file system will invoke VOP_WRITE() on its
:vnodes to avoid understanding file system internals, so you can have such
:operations shared across file systems using UFS. If there is caching
:happening above VOP_WRITE(), will changes get propagated up the stack? Or
:does VOP_WRITE() change so that it talks to the memory object which then
:talks to VOP_REALLYWRITE()?
There are a number of places where the kernel opens and then manipulates
files with VOP calls. That's been a major eyesore, frankly. We would
change those instances to open and manipulate files through
struct file's (like it should have been done in the first place).
:Also, what implications does this have for security-oriented revocation?
:Memory mapping has always been a problem for revocation, but a number of
:interesting pieces of work have been done wherein access to a file is
I don't think there are any implications. Rather then scanning for a
vnode we instead just scan for an opaque data pointer in the struct
file. It might not be quite that trivial, but it wouldn't be difficult
either. mmap is another matter, but certainly no more difficult then
it would be with the current scheme.
:Also, however this is implemented, it would be nice to consider supporting
:stateful access to devices: i.e., dev_open() returns a state reference
:that is fed into future operations, so that pseudo-devices emulating
:multi-instance devices from other platforms can operate correctly. In my
I was thinking more like allocating a struct file, filling it in with
defaults, then passing it to dev_open() which would override the
defaults as necessary. In otherwords, the open function manipulates
the struct file and is otherwise completely opaque to the caller.
:use), or we need a more general state management technique. In any case,
:one thing this means is that if operations are pushed through a virtual
:memory object, different "instances" must have different objects...
If the fileops must handle mmap, then the VM object would be directly
associated with the fileops. If a file has an associated vnode there
might also be a VM object reference in the vnode (assuming we don't
merge them), but it would be opaque to the rest of the system.
-Matt
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200104181842.f3IIg9D38399>