Date: Wed, 22 Jan 2003 20:16:49 -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: <200301230416.h0N4GnRv017989@apollo.backplane.com> References: <20030122173229.D46974-100000@mail.chesapeake.net> <200301222249.h0MMn9e5016697@apollo.backplane.com> <200301222323.h0MNN7co043532@khavrinen.lcs.mit.edu> <200301230259.h0N2xt9R017635@apollo.backplane.com> <200301230343.h0N3hfXt044969@khavrinen.lcs.mit.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
:> 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
:
:No, you haven't explained a damn thing. You haven't even stated the
:problem at all. Tell me, once and for all, WTF is wrong, technically,
:with the shm_open interface. Don't give me any NIH crap, I'm not
:interested in hearing your theories on technical elegance or what not.
:We have a standard interface. Given a lack of a clear problem
:statement, I can only conclude that the interface *can* do what you
:seem to be saying you want it to do (it was good enough for SSWG-RT),
:but that you are for some reason firmly attached to your pet interface
:instead. How the current implementation of shm_open() works is
:entirely irrelevant; my desire is to replace it.
Did you even bother reading any of my prior postings? Fine then, I'll
explain it again, for the fourth time.
We need a shared memory mechanism that is swap-backed.
It's that simple. I'll repeat it. For the Fifth time:
We need a shared memory mechanism that is swap-backed.
Understand the problem now? shm_open() as it currently stands does not
in any way give us the above.
Now, I think I understand what you are getting at. You seem to believe
that implementing shm_open() in the kernel is the solution. There's a
serious problem with doing this, however. Actually, there are two problems
with doing this:
(1) We don't have the kernel infrastructure to support it without a lot
of hacks. i.e. we need a file-descriptor based vector array for
high level descriptor based system calls in order to implement
shm_open() properly in the kernel if we want to have any hope of
keeping it compatible, or growing its compatibility, with other
implementations.
(2) You are talking about a fairly complex API in its full glory. In
its full glory shm_open() needs to deal with both private and public
name spaces.
Implementing this in the kernel makes very little sense to me when
the same thing can be implemented in userland at a far lower cost and
far lower complexity.
Hence, the current proposal is to implement a far simpler system call,
one that simply returns a memory descriptor. This far simpler system call
can eventually be leveraged in the userland implementation of shm_open(),
at a far lower development cost. For example, Peter brought up the
idea of using the solaris fattach() and related system calls as a means
to give a memory descriptor public namespace support, and private namespace
support can just as obviously be implemented within libc.
As has been already discussed, some of the aspects of shm_open() do not
lend themselves well to kernel implementation -- namely the private
namespace support. In a previous email you seem to reject the whole
concept of a private namespace but you can't argue that and also argue
that we should implement it in the kernel, because then we wind up with
a non-standard implementation of a standard's based function name.
Now if you, personally, are willing to put in the huge amount of work
necessary to implement shm_open(), in its full glory, in the kernel,
I think that's just dandy. But if you aren't (and in your previous emails
you don't seem to be willing to follow the shm_open() API in its full
glory in a kernel implementation), then I don't see any advantage to
regressing our shm_open() interface and instead I would far rather
implement the simpler interface in the kernel and then, once we get all
the proper support in down the line, use it to back a fully implemented
userland shm_open(). I am recommending a course of action that allows
us to incrementally achieve the same goals at a far lower cost. You seem
to be trying to force a course of action, which you are not willing to
undertake yourself, which achieves the goals at far higher cost,
complexity, and with more hacks to the kernel. I'm sorry if you
don't agree with me but that is my take on the situation. I really
dislike hacking random code in the kernel unless its absolutely
necessary.
-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?200301230416.h0N4GnRv017989>