Re: Kernel support for peer-to-peer protection models...

[Ivan Godard]

----- Original Message ----- 
From: "Davide Libenzi" <davidel@xxxxxxxxxxxxxxx>
To: "Ivan Godard" <igodard@xxxxxxxxxxx>
Cc: "Paul Mackerras" <paulus@xxxxxxxxx>; "Linux Kernel Mailing List"
<linux-kernel@xxxxxxxxxxxxxxx>
Sent: Sunday, March 28, 2004 7:48 PM
Subject: Re: Kernel support for peer-to-peer protection models...


> > > Ivan Godard writes:
> > >
> > > > 3) flat, unified virtual addresses (64 bit) so that pointers,
including
> > > > inter-space pointers, have the same representation in all spaces
> > >
> > > How are you going to implement fork() ?
> >
> > The usual COW using the page tables. The child keeps the same code space
but
> > gets a new data space. I expect that specialized versions of fork will
give
> > explicit control over which space the child gets, but in comman usage no
one
> > cases just as no one cares which PID it gets.
>
> Uh?
>
> int myexec(char const *cmd) {
>
> if (!fork()) {
> exit(exec(cmd));
> }
> ...
> }
>

Ah! you wanted to know about exec, not fork. A true fork() is pretty rare
these days anyway. Still, the answer is pretty much the same: the fork()
gets you a new data space, retaining the old code space, and the exec()
finds (or creates) the code space that cmd's code is in and switches the
active code space to that space. Heritable data, such as file descriptors,
won't have been in the old data space anyway, so the child references them
through syscalls just as in a conventional.

Perhaps I'm missing your question here, but in general we see no problem
with fork/exec in our model - it's one of the least changed things. You
always get a new address space on a conventional, and you also do with a
Mill; the only difference is that you don't have to shoot down the cache or
TLB, so a fork/exec should be quite a bit faster.

Ivan


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/