* 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