Role of "init" section of emu config files?

What is the purpose of the "init" section of the emu config files, eg
/emu/MacOSX/emu? Changing it seems to have no effect, and the default
is specified in /emu/port/main.c. The only override i can see is the
argument to -d.

Come to think of it, it looks hard-coded in native mode, too, as the
argument to disinit in, for example, /os/pc/main.c (although i've not
given the build machinery for native kernels much examination in quite
a while).

Is this section simply documentation in one or both cases?

Re: Role of "init" section of emu config files?

> Come to think of it, it looks hard-coded in native mode, too, as the
> argument to disinit in, for example, /os/pc/main.c (although i've not
> given the build machinery for native kernels much examination in quite
> a while).

no, it's not hard coded in native: the init section tells which file's contents become
/osinit.dis (that name is fixed but not its contents)

since the root section can now give arbitrary files (which it wasn't, originally), probably
the contents of /osinit.dis could just as well be set that way too, and indeed it should now work too,
given the way the init section works.

Re: Role of "init" section of emu config files?

> What is the purpose of the "init" section of the emu config files, eg
> /emu/MacOSX/emu? Changing it seems to have no effect, and the default
> is specified in /emu/port/main.c. The only override i can see is the
> argument to -d.

you're right that it should probably do something more than set /osinit.dis
(if that's specified in "root") which then isn't used in hosted mode.
we currently run arbitrary programs, not using -d, but by passing extra
arguments to emuinit.dis itself using the host's command line:

exec /usr/inferno/Plan9/$cputype/bin/emu -c1 -b -pimage'='32777216 -pheap'='48000000 -g950x600
/dis/wm/wm.dis charon -x 1 -y 1 -width 950 -height 600 $*

to start a window system running charon, for instance.

devip connect error state

So -- in devip on Inferno hosted we have this bit of code: (connectctlmsg)

       if(c->state != Idle)
                error(Econinuse);
        c->state = Connecting;
        ...
        if(waserror()){
                qlock(&c->l);
                c->state = Connected;   /* sic */
                nexterror();
        }
        /* p = x->connect(c, cb->f, cb->nf); */
        so_connect(c->sfd, ip6w(c->raddr), c->rport);
        qlock(&c->l);
        poperror();

In native inferno (and Plan 9) devip we have this bit of code:
        if(c->state != 0)
                error(Econinuse);
        c->state = Connecting;
        ...
        if(waserror()){
                qlock(c);
                nexterror();
        }
        sleep(&c->cr, connected, c);
        qlock(c);
        poperror();

------------------

Re: devip connect error state

On 8/8/07, Eric Van Hensbergen <ericvh <at> gmail.com> wrote:

> So, bug or feature?  At the very least it would seem a good idea to
> set c->state to Hungup (and also change the c->state != 0 to a
> c->state != Idle).  I have no idea why we set c->state to Connected in
> Inferno hosted -- that just seems completely bonkers.

It actually looks like a cut and paste error -- cut, paste, forget to
change the rvalue.

ron

Re: sniffing under hosted-inferno

hello

after a bit of reading seems that doing this with linux is a bit
problematic, at least with modern distributions.

seems that each distribution has its own security thing, for example
novell has apparmor and fedora has selinux, and both of them do not
care about any capabilities one may have, so each distribution seems
to needs a different approach.

tun/tap drivers are also binded to this thing, i suppose i'll run emu
as root to test it, but i would like some advice on how to do this in
a convenient way if there is any ;)

anyway i think on bsd systems with bpf device and perms for
reading/writting to /dev/bpf is enough so there is no need to run as
root, or to have capabilities and the like.

thanks

gabi

On 7/23/07, Eric Van Hensbergen <ericvh@...> wrote:
> You could patch in with tun/tap and use a virtual mac as well potentially...
>
>             -eric
>
>
> On 7/23/07, Charles Forsyth <forsyth@...> wrote:
> > i think that historically the raw interfaces in unix were restricted

Inferno ds google group

To encourage transparency in the development process I've created a
new google group for communications related to my gsoc project. Please
check it out here:

http://groups.google.com/group/inferno-ds

Noah

executeonnewstack

Re: executeonnewstack

it's turning itself into the first newproc() and wants a stack with an address in
shared memory that will work properly (ie, address the memory on that stack)
in every subsequently-created kproc.

From: Howard Fan <fan.howard@...>
Subject: [inferno-list] executeonnewstack
Date: 2007-08-13 10:35:24 GMT

Re: executeonnewstack

That reminds me of something I like to cite, when advicing on
programming practices, specially as I didn't follow this advice for a
long time, although now I try to.
(http://www.thinkingparallel.com/2007/03/20/ten-questions-with-joe-armstrong-about-parallel-programming-and-erlang/):
"Michael: What is the worst mistake you have ever encountered in a
Erlang program?
Joe: Programs without documentation - I hate it when people say "read
the code" - the code is the *solution* to a problem - by reading the
code I have to *guess* what the problem was, and this is error prone.
I like to be
told what the problem was, not guess. So the worst mistake was when I
wrote a multi-page comment to explain some particular tricky point in
a program only to find that in a later version somebody had removed
the entire comment."

(I'm not complaining on that Inferno's code, which I haven't even read)
2007/8/13, C H Forsyth <forsyth@...>:
> it's turning itself into the first newproc() and wants a stack with an
> address in
> shared memory that will work properly (ie, address the memory on that stack)
> in every subsequently-created kproc.
>
> ---------- Missatge reenviat ----------
> From: "Howard Fan" <fan.howard@...>
> To: inferno-list@...
> Date: Mon, 13 Aug 2007 18:35:24 +0800
> Subject: [inferno-list] executeonnewstack
> Why emu/Linux/os.c:^libinit uses executeonnewstack instead of straight
> emuinit(imod) as in Nt/os.c?
>
>
>
>