Date: Wed, 22 Jan 2003 18:59:55 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: Garrett Wollman <wollman@lcs.mit.edu> Cc: <arch@FreeBSD.ORG> Subject: Re: getsysfd() patch #1 (Re: Virtual memory question) Message-ID: <200301230259.h0N2xt9R017635@apollo.backplane.com> References: <20030122173229.D46974-100000@mail.chesapeake.net> <200301222249.h0MMn9e5016697@apollo.backplane.com> <200301222323.h0MNN7co043532@khavrinen.lcs.mit.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
:> Moving shm_open() to kernel space? That's a pretty tall order. I
:> don't think anyone has proposed that until now.
:
:It was always my expectation that this would happen at some point.
You are welcome to try, but I would consider it a big mistake.
:> I would argue that namespace private operations are far better handled
:> in userspace then kernelspace (why waste kernel memory managing
:> private namespaces?).
:
:Private namespaces are bad and unnecessary. We already have anonymous
:shared memory; I don't see any need for ``semi-anonymous'' shared
:memory. The garbage-collection problem is already bad enough.
I have no idea what you are talking about here. We can do swap-backed
anonymous shared memory using SysV shared memory (non descriptor-based),
and we can emulate anonymous shared memory using shared files (descriptor
based), but we have no descriptor-based shared memory mechanism that
uses swap backing store and that is primarily what most people need
when they need shared memory. These are not minor differences. It is
a huge problem to people who use shared memory regularly like Peter,
and me as well. I had to go through loops to make shared memory work
in the Diablo news system and I sure wish I had getmemfd() back then!
:You haven't provided any justification that I've seen for introducing
:a new interface when the one we've got can already do that.
We have no interface that has any capability to do what we want.
I've explained to you what the problem is several times now in
exruciating detail and you have ignored me every time, disputing the
conclusion without providing anything to back up your assertion. I am
going to explain again in the next sentence: We have no descriptor-based
shared memory mechanism which uses swap as backing store. It's that
simple.
If you believe that such a mechanism already exists then, by all means,
tell us all what it is.
:> To do that requires a two-stage process of which my current proposed
:> patch is only stage-1, since we have no current ability to call
:> ftruncate() on a descriptor, only a vnode.
:
:Trivial under my proposal... here's the conceptual patch:
That's a terrible hack. I would never implement that. It's bad enough
that mmap() has to be hacked. I would far prefer to implement a
high-level operations vector on descriptors that covers both mmap() and
ftruncate() (at a high level), not add more low level hacks. I believe
it makes sense to hack mmap() in the proposed stage-1 patch, but that's
about as far as I am willing to go. The next step would be a high level
operations vector.
Again, I have reiterated the technical details of the problem and the
proposed solution. If you believe a solution is possible without adding
another system call I'm all ears.
-Matt
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200301230259.h0N2xt9R017635>