From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <20100912193047.GC3919@fangle.proxima.alt.za> References: <20100912161716.GB3919@fangle.proxima.alt.za> <20100912193047.GC3919@fangle.proxima.alt.za> Date: Sun, 12 Sep 2010 22:26:20 +0200 Message-ID: From: yy To: lucio@proxima.alt.za, Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [9fans] 9vx/vx32 - Out of ignorance Topicbox-Message-UUID: 5688202c-ead6-11e9-9d60-3106f5b1d025 2010/9/12 Lucio De Re : > It's very, very helpful. =A0I would, and almost certainly will, have > split the "tunnel" and "openvpn" portions into two scripts (a selector > of some type might be good enough, but isn't easily justified), because > I'm sure that they don't overlap quite the way the present shape of the > script suggests. =A0I found it after posting my request, I still haven't > got everything working to my satisfaction, but I think the reference to > qemu will help. The 9vx-tap script is quite naive. I decided to leave it that way because its purpose is more to serve as documentation than as something you will actually use. It is the simplest script I could come up with, but can be improved in many ways. > There are still questions unanswered: (1) would switching userid be > useful and practical, irrespective of the actual need for it? I'm not sure why you would want to do that, but I'm with ron: if you are interested, go ahead. > and (2) > would it make sense to migrate the virtual network devices to vx32? Why? The network devices are actually quite simple, and I guess you could move the core to libvx32, but I don't know what you gain with that. As I see it, I like the current situation where vx32 is a sandboxing library and 9vx takes care of providing the virtual devices. --=20 - yiyus || JGL . 4l77.com