From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <5d375e920711130418r6cf0aef4n928cc5b811e1a7d9@mail.gmail.com> Date: Tue, 13 Nov 2007 13:18:56 +0100 From: Uriel To: "Fans of the OS Plan 9 from Bell Labs" <9fans@cse.psu.edu> Subject: Re: [9fans] Glendix? In-Reply-To: <473980C6.4040009@kix.in> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <47396E4D.6020005@kix.in> <473980C6.4040009@kix.in> Topicbox-Message-UUID: f6d72022-ead2-11e9-9d60-3106f5b1d025 On Nov 13, 2007 11:47 AM, Anant Narayanan wrote: > Hi, > > > so you might get more hardware support, but you'd lose all the userspace > > code, so would it really end up that much more capable? > > I don't understand what "lose all the userspace code" means. The > objective of the exercise is to enable Plan 9's userspace to work > unmodified on Linux. I still think being able to run lunix programs in the same environment would be quite useful (and not too hard, you could use namespaces to build a more 'lunix friendly' environment inside glendix). Otherwise it would not be too different from running native plan9 inside a VM as Gorka pointed out. (And that is is IMHO what makes THNX not particularly useful, that it adds very little over just running Plan 9 on qemu, or vmware, or whatever. > It boils down to Linux's drivers/schedulers/et.al. but Plan 9's > programming environment. You'd still use /net to do network programming, > use libdraw and not X, so to the programmer the fact that the > distribution is running the Linux kernel is not known. > > Performance-wise, I see how it would be a bad idea; since read/write to > /net will ultimately result in a socket-like call, so there would be a > overhead. If that is an issue you could eventually swap inferno for an in-kernel /net server (using the new 9p server bits of v9fs). The beauty of the approach is that it works nicely in steps, and if you want to do that change later on you wont need to change anything else. uriel