Date: Fri, 25 Jan 2002 14:43:40 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Julian Elischer <julian@elischer.org> Cc: Poul-Henning Kamp <phk@critter.freebsd.dk>, Robert Watson <rwatson@FreeBSD.ORG>, Kirk McKusick <mckusick@mckusick.com>, Rik van Riel <riel@conectiva.com.br>, freebsd-hackers@FreeBSD.ORG, Matt Dillon <dillon@earth.backplane.com>, David Xu <bsddiy@21cn.com> Subject: Re: vm balance Message-ID: <3C51DF9C.F73AF275@mindspring.com> References: <38778.987605692@critter> <3ADDCDCA.86D1B3BE@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 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?3C51DF9C.F73AF275>