Nathaniel W Filardo wrote:
Just a reminder, nothing novel: if you don't mind being root on the host
briefly (to run ifconfig, brctl, and tunctl commands), you can create a new
TAP interface (and use the file descriptor in 9vx to back a devether) and
use Linux's bridging to get ethernet frames to
On Tue, Jul 08, 2008 at 01:17:53PM -0400, Russ Cox wrote:
> > i guess this gets to a more philosophical question
> > on how 9vx networking relates to the host.
> >
> > personally, i feel it would be more useful to be
> > able to use plan 9's native network stack. but
> > i'm biased. i want to se
> I intend 9vx to be a very thin layer atop the host's
> resources, not a second machine that you have
> to administer. If you want a second machine, there is
> always VMware.
as far as i know, neither plan 9 terminals nor cpu servers
need individual administration.
- erik
> here's the symptom
>
> ndb/dnsquery 9hal.ath.cx
> 9hal.ath.cx ip 9.0.0.0
Fixed. Instead of the tacky solution, one can check
the return value from v4parseip.
> on a related note, would it be worth while to
> put effort into supporting ptr queries, ip6 &c using
> the host's lookup
> > personally, i feel it would be more useful to be
> > able to use plan 9's native network stack. but
> > i'm biased. i want to send aoe/cec/il packets.
> >
>
> Part of the reason I have not stopped using lguest, although now I use
> both 9vx and lguest.
>
> You could write a plan 9 device fo
On Sun, Jul 6, 2008 at 8:56 AM, erik quanstrom <[EMAIL PROTECTED]> wrote:
> personally, i feel it would be more useful to be
> able to use plan 9's native network stack. but
> i'm biased. i want to send aoe/cec/il packets.
>
Part of the reason I have not stopped using lguest, although now I use
here's the symptom
ndb/dnsquery 9hal.ath.cx
9hal.ath.cx ip 9.0.0.0
the problem is that devip.c:/^lookuphost tries
to avoid calling gethostbyname when given an
ip address by testing to see if the return value
of v4parseip is nozero. unfortunately, v4parseip
parses "9hal.ath.cx" a
