9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
* [9fans] GSoC proposal: Ventilator or Access to host's devices
@ 2014-03-11  8:39 tuchalia
  2014-03-17 11:42 ` Charles Forsyth
  0 siblings, 1 reply; 2+ messages in thread
From: tuchalia @ 2014-03-11  8:39 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

[-- Attachment #1: Type: text/plain, Size: 482 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 962 bytes --]

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: [9fans] GSoC proposal: Ventilator or Access to host's devices
  2014-03-11  8:39 [9fans] GSoC proposal: Ventilator or Access to host's devices tuchalia
@ 2014-03-17 11:42 ` Charles Forsyth
  0 siblings, 0 replies; 2+ messages in thread
From: Charles Forsyth @ 2014-03-17 11:42 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

[-- Attachment #1: Type: text/plain, Size: 1871 bytes --]

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
> 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.

[-- Attachment #2: Type: text/html, Size: 2962 bytes --]

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2014-03-17 11:42 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-03-11  8:39 [9fans] GSoC proposal: Ventilator or Access to host's devices tuchalia
2014-03-17 11:42 ` Charles Forsyth

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).