> >> i find there's a certain simplicty in dealing directly
> >> with hardware, provided one has documentation.
> >
> > Provided it is complete and the h/w well designed and
> > interface regular. Unfortunately not all that common.
>
> you continue with this claim without presenting evidence.
>> no, it doesn't. on plan 9, when the shell script exits,
>> nothing will have vacfs mounted anymore, so vacfs
>> will get an eof on the 9p connection and exit.
>> that's why i put an rfork n in the script.
>
> aha, that's probably what the rfork call does ?
rfork n forks the name space, so tha
On Sat, Jun 14, 2008 at 9:53 AM, erik quanstrom <[EMAIL PROTECTED]> wrote:
>> I don't know how the praise of "excellent" was bestowed on QEMU. It
>> may work well on a x86 emulating an x86 but try something else. It
>> ends in tears.
>>
>
> this isn't a defense of qemu. i don't know enough about i
>> i find there's a certain simplicty in dealing directly
>> with hardware, provided one has documentation.
>
> Provided it is complete and the h/w well designed and
> interface regular. Unfortunately not all that common.
you continue with this claim without presenting evidence.
i respond to th
> I don't know how the praise of "excellent" was bestowed on QEMU. It
> may work well on a x86 emulating an x86 but try something else. It
> ends in tears.
>
this isn't a defense of qemu. i don't know enough about it
to defend it.
however, why is it a requirement that a vm be able to emulate
ot
* Russ Cox <[EMAIL PROTECTED]> wrote:
Hi,
> no, it doesn't. on plan 9, when the shell script exits,
> nothing will have vacfs mounted anymore, so vacfs
> will get an eof on the 9p connection and exit.
> that's why i put an rfork n in the script.
aha, that's probably what the rfork call does ?
