Re: [9fans] Help with device and clone?

Re: [9fans] Help with device and clone?

[Devon H. O'Dell]

Meh, I keep forgetting to hit reply-all or something.

2008/12/19 erik quanstrom <quanstro@quanstro.net>:
>> That's where I was looking initially -- it looks like that's all only
>> done when you're connecting to a venti, and it seems like it
>> definitely happens after the links run anyway. Links happen after
>> initseg(); that stuff happens in bootinit() in Plan 9 proper -- so
>> that's where I did it in 9vx. I'm tempted to just use '#l' in
>> ip/chandial.c right now until I have a more concrete idea about where
>> binds *should* happen. There are still issues with etherve that I need
>> to hammer out, I think.
>>
>> --dho
>
> sorry.  i haven't really been following along.  i am confused
> by the fact you're having troubles.  if you're doing things in
> the same order as the native kernel, i don't see how you
> could be getting different results.  unless there is some hack
> in 9vx that causes things to happen differently.

There seem to be some differences in how things happen at start-up
time, but they don't seem so severe. That's why I'm asking here :)

> (you're virtual ether0 is working now, right?)

It works if I force chandial to look for it in '#l', and by works, I
mean I haven't been able to test it on a live network yet :(

--dho

> - erik
>

Re: [9fans] Help with device and clone?

[erik quanstrom]

i did get the original.

- erik

[9fans] Help with device and clone?

[Devon H. O'Dell]

I really am getting to the deep guts of dev.c and chan.c here in
debugging why when ip/ipconfig tries to open /net/ether0/clone, it's
getting Enotfound. From my latest commit:

Fix some stuff with the ether controller attaching. It attaches now, but for
some reason clone screws up. I have no idea why; domount is failing to work
in 9vx/a/chan.c when we are doing the walk over the path which in turn causes
us to try to find the file in rootgen instead of going to the other side of
the mount and looking for it in /ether0/clone. Help?

It's entirely possible (and almost entirely clear) that I'm missing
something obvious, but I'm not sure what it is. The virtual device is
at http://testbed.dh0.us:8000/file/dfc493421329/src/9vx/etherve.c for
the current revision -- feel free to browse around or clone my repo.
I'm going to sleep now, but any help would be appreciated.

--dho

Re: Help with device and clone?

[Devon H. O'Dell]

Hey all,

So the problem turned out to be that somehow, when ethermediumlink()
is called, its view of the namespace doesn't include /net as a
separate mount. So I figured the devroot reset routine was getting
called somehow after all the ip stuff attached. I reordered stuff to
attempt to guarantee this wasn't the case, but didn't have much luck
with that either. However, manually changing all the chandial lines to
use #l/ether0 (instead of argv[2], which was /net/ether0) causes stuff
to `just work'.

Clearly my idea of what's happening in what order is kind of screwy.
I've plopped things in various orders, but the only way things are
running is if I use that hack. I see that '#l' is bound to /net in
/lib/namespace, so it's happening before rio starts (and even if
that's not where that happened; I put a bind -a '#l' /net in
/usr/glenda/lib/profile prior to rio starting and that didn't help).
Regarding the order of things:

I'm calling links() after initseg() as it is in Plan 9's main.c;
inside links(), I call ethervelink() (my virtual ethernet driver),
ethermediumlink(), netdevmediumlink() and loopbackmediumlink().

Any ideas now that the issue is a bit less arcane?

--dho

Re: Help with device and clone?

[Russ Cox]

> So the problem turned out to be that somehow, when ethermediumlink()
> is called, its view of the namespace doesn't include /net as a
> separate mount. So I figured the devroot reset routine was getting
> called somehow after all the ip stuff attached. I reordered stuff to
> attempt to guarantee this wasn't the case, but didn't have much luck
> with that either. However, manually changing all the chandial lines to
> use #l/ether0 (instead of argv[2], which was /net/ether0) causes stuff
> to `just work'.
>
> Clearly my idea of what's happening in what order is kind of screwy.
> I've plopped things in various orders, but the only way things are
> running is if I use that hack. I see that '#l' is bound to /net in
> /lib/namespace, so it's happening before rio starts (and even if
> that's not where that happened; I put a bind -a '#l' /net in
> /usr/glenda/lib/profile prior to rio starting and that didn't help).
> Regarding the order of things:
>
> I'm calling links() after initseg() as it is in Plan 9's main.c;
> inside links(), I call ethervelink() (my virtual ethernet driver),
> ethermediumlink(), netdevmediumlink() and loopbackmediumlink().
>
> Any ideas now that the issue is a bit less arcane?

The link routines happen very early, before any user code has run.
/lib/namespace is processed by user code.
So when the links are running, I think it is simply
that there is nothing bound to /net.

Russ

Re: [9fans] Help with device and clone?

[Devon H. O'Dell]

> The link routines happen very early, before any user code has run.
> /lib/namespace is processed by user code.
> So when the links are running, I think it is simply
> that there is nothing bound to /net.
>
> Russ
>
Thank you... I think I see the issue now. I'm also enjoying:

245                         /* set up the network so we can talk to
the venti server */
246                         /* this is such a crock. */

Yes, yes it is...

--dho

Re: [9fans] Help with device and clone?

[erik quanstrom]

> Thank you... I think I see the issue now. I'm also enjoying:
>
> 245                         /* set up the network so we can talk to
> the venti server */
> 246                         /* this is such a crock. */
>
> Yes, yes it is...
>
> --dho

we would all love it if you allowed venti to accept
a fd instead of a tcp connection.

- erik

Re: [9fans] Help with device and clone?

[Devon H. O'Dell]

2008/12/18 erik quanstrom <quanstro@quanstro.net>:
>> Thank you... I think I see the issue now. I'm also enjoying:
>>
>> 245                         /* set up the network so we can talk to
>> the venti server */
>> 246                         /* this is such a crock. */
>>
>> Yes, yes it is...
>>
>> --dho
>
> we would all love it if you allowed venti to accept
> a fd instead of a tcp connection.

Maybe I will try to after I understand this a bit better, because it's
still not working, and I'm introduced with a couple of issues that I'm
still not coming around with solutions for -- that set-up is a really
huge hack. I guess I knew it was like that.

It seems to be a chicken-and-egg type problem, which I don't think it
is. I can't really kbind("#I", "/net", MAFTER); at the time that I'm
calling ethermediumbind -- it's too early for that. At the same time,
I can't really move the links and makekprocdev(&ipdevtab); to the area
in init0() where kbind()s happen. Maybe I'm missing something totally
obvious here, but there must be some way for me to call
ethermediumbind() and change its namespace view -- but so far
nothing's happening when I add:

kbind("#Zplan9/", "/", MAFTER);
+kbind("#I", "/net", MAFTER);
+kbind("#l0", "/net", MAFTER);
kbind("#p", "/proc", MREPL);

in init0.

--dho