On Sat, Jan 11, 2025 at 04:52:05PM +0100, tlaro...@kergis.com wrote:
> [I restarted a special thread because the hier was getting deep and
> mixed. Here are the last bits bits taken out and
> reproduced for reference before questions.]
>
> >From Paul Lalonde, relating to a commit to
> https://gi
On Sat, Jan 11, 2025 at 7:53 AM wrote:
> 1) Could PROCESS be whether updated or archived to not have
> instructions related to an obsolete process? Is
>
> http://groups.google.com/group/nix-dev
That file has no relevance, and should be deleted as part of regen.
PRs welcome.
So the answ
Paul just fixed our multiboot header issue, it now hangs in vmx,
instead of being rejected by vmx (side note: vmx is worth learning
from).
There is a little trick Geoff developed for debugging this early code,
you all may have seen it:
(from memory, looks like this)
#define WAVE(c) MOVB $c, AL; OU
I forget the plan 9 assembly, or even if plan 9 assembly supports that
syntax, but:
MOVB $c, AL; .byte 0xE6 ; .byte 0xF8; .byte 03
should do the same thing
On Sat, Jan 11, 2025 at 1:14 PM Ron Minnich wrote:
>
> Paul just fixed our multiboot header issue, it now hangs in vmx,
> instead of being r
I'm writing a very simple device, #Y, whose only function is to pass
system calls through from a guest VM to a host. The pathnames are
unchanged.
It's basically working, save, as usual, I got confused by walk.
When I try to open '#Y", the first name in the walk is ... #Y. This
surprised me.
I do
[I restarted a special thread because the hier was getting deep and
mixed. Here are the last bits bits taken out and
reproduced for reference before questions.]
>From Paul Lalonde, relating to a commit to
https://github.com/rminnich/nix-os
(the main branch is now regen)
---8<---
#!/bin/rc
git/