Julian Elischer wrote:
> You can mmap() devices and you can mmap files..
>
> you cannot mmap FIFOs or sockets.
>
> for this reason I think that devices are still well represented by
> vnodes. If we merged vnodes and vm objects,
> then if devices were not vnodes, how would you represent
> a vm area that maps a device?
Merging vnodes and vm objects is an incredibly bad idea. There
is a lot of other work that should be done before that can even
be considered, and then it shouldn't be considered.
In othe words, it's a good excuse for getting some needed
changes in, but it's not a good idea.
I know you and Kirk love the idea, but, truly, it is a bad
idea.
As far as the other work is concerned:
o Get rid of struct fileops
o Get rid of specfs entirely; using vp's
o Fix the permission/ownership problems on
FIFOs and sockets that results from the
use of struct fileops
o Fix range locks on non-file objects
o Move the lock list to the vnode
o Make the VFS advisory locking into a
veto-based interface, which only has
something other than "return 0;" on
the NFS client code
o Delay lock coelescing until after the
attempt has *not been* vetoed, in order
to save wire traffic in the "local lock
conflict" case
o Consider getting rid of lock coelescing
entirely, by default, in order to comply
with the NFSv4 RFC non-coelescing of
locks requirement
o Allow MMAP'ing of FIFO object
o Constrain the buffer size to a multiple
of a page size, instead of the weird
value of "5K".
o Implement them slightly differently
o Get rid of fifofs
o Give up on the idea of mmaping streams, since to
do that would require constraining mbufs to page
sized chunks per mbuf, at least on the receive
case, since there are adjacency problems with
mapping consecutive packets that don't represent
the same flow (unless you are willing to rewrite
all the firmware in the world, in which case,
"go for it!" 8-)).
-- Terry
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
