From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 Date: Tue, 11 Mar 2014 09:39:26 +0100 Message-ID: From: tuchalia To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=047d7b2e0ddf62333d04f450a8e8 Subject: [9fans] GSoC proposal: Ventilator or Access to host's devices Topicbox-Message-UUID: c7b89d74-ead8-11e9-9d60-3106f5b1d025 --047d7b2e0ddf62333d04f450a8e8 Content-Type: text/plain; charset=ISO-8859-1 Hi everyone! I'm trying to get to work on the Ventilator project during the GSoC, and in order to have a good proposal I'm asking for some information here. Where should I start looking? Also, I have just seen this: http://www.vitanuova.com/inferno/man/2/venti.html Is it still possible to get to work on this as a SoC project? If it isn't, I may still be interested on working on "Access to host's devices*"*, so where can I start looking with that? -- Daniel --047d7b2e0ddf62333d04f450a8e8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi everyone!

I'm trying to get to w= ork on the Ventilator project during the GSoC, and in order to have a good = proposal I'm asking for some information here.
Where should I= start looking?


Also, I have just seen this:=A0http://www.vitanuova= .com/inferno/man/2/venti.html
Is it still possible to get to = work on this as a SoC project?

If it isn't, I may still be interested on working o= n "Access to host's devices", so where can I st= art looking with that?

--
Daniel
--047d7b2e0ddf62333d04f450a8e8-- From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: Date: Mon, 17 Mar 2014 11:42:36 +0000 Message-ID: From: Charles Forsyth To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=089e013d1c687a988c04f4cbea0e Subject: Re: [9fans] GSoC proposal: Ventilator or Access to host's devices Topicbox-Message-UUID: cb711068-ead8-11e9-9d60-3106f5b1d025 --089e013d1c687a988c04f4cbea0e Content-Type: text/plain; charset=UTF-8 On 11 March 2014 08:39, tuchalia wrote: > If it isn't, I may still be interested on working on "Access to host's > devices*"*, so where can I start looking with that? > The old way way was to add an internal virtual device to Inferno's emu or 9vx or drawterm. I think the best way to implement that access now is by writing a separate program that provides a name space representing the devices which it serves using 9P. That program can be host-specific where necessary. For example, Linux systems provide a fairly uniform interface across Linux platforms (except for embedded Linux such as Android), and the interface program would mainly need to be recompiled for each host platform; the BSD systems will be similar in effect to Linux but often different in detail; and Apple and WIndows are distinct targets different from them all. The name space exported for a particular type of service (audio, or serial ports, say) should be the same across all hosts, even when the different host systems have themselves got different interfaces. It should ideally support many clients at once. The advantage over an internal virtual device is that the same 9P-serving program can be used by Inferno, 9vx and drawterm, even simultaneously, and exported directly or indirectly to a network. Also, as we've found especially with graphics, the internal concurrent programming environment of a virtual operating system written in C often clashes with the programming environment required by the host to access its services. It's most obvious with Apple, where Objective C is needed, but it has turned out to be true for X11 as well. In some cases, it might be convenient to take the result and make it an internal virtual device after all, when that works, but separate development initially will still be convenient. --089e013d1c687a988c04f4cbea0e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On 11 March 2014 08:39, tuchalia <tuchalia@gmail.com> wrote= :
If it isn't, I may still be interested on working on "Access to host's d= evices"= ;, so where= can I start looking with that?

The old way way was= to add an internal virtual device to Inferno's emu or 9vx or drawterm.=

I think the best way to implement that= access now is by writing a separate program that provides a name space rep= resenting the devices
which it serves using 9P. That program can be ho= st-specific where necessary. For example, Linux systems provide a fairly un= iform interface across Linux platforms (except for embedded Linux such as A= ndroid), and the interface program would mainly need to be recompiled for e= ach host platform;
the BSD systems will be similar in effect to Lin= ux but often different in detail;
and Apple= and WIndows are distinct targets different from them all.

The name space exported for a particul= ar type of service (audio, or serial ports, say) should be the same across = all hosts,
even when the different host sys= tems have themselves got different interfaces. It should ideally support ma= ny clients at once.

The advanta= ge over an internal virtual device is that the same 9P-serving program can = be used by Inferno, 9vx and drawterm,
even = simultaneously, and exported directly or indirectly to a network. Also, as = we've found especially with graphics, the internal
concurrent programming environment of a virtual = operating system written in C often clashes with the programming environmen= t required
by the host to access its servic= es. It's most obvious with Apple, where Objective C is needed, but it h= as turned out to be true for
X11 as well.
In some cases, it might be convenient to = take the result and make it an internal virtual device after all, when that= works,
but separate development initially will still be= convenient.


--089e013d1c687a988c04f4cbea0e--