I think it would be pretty easy to follow the pattern of including nix
conditionally in a conf file so you would have instead of pc64 , nixpc64.
I’m already doing that with my VM threads kernel — It’s an unchanged kernel
with just two additional lines to add a new device and support code.
There’s
On Wed, Jan 29, 2025 at 07:14:10AM -0800, ron minnich wrote:
> I agree with (1), vmx is not ready for nix yet.
> as for (2), I'll take a slight change: the goal is to remove nix as an
> independent entity, and subsume it in other plan 9 kernels (I prefer 9front
> at this point)
>
> Big picture, NI
I agree with (1), vmx is not ready for nix yet.
as for (2), I'll take a slight change: the goal is to remove nix as an
independent entity, and subsume it in other plan 9 kernels (I prefer 9front
at this point)
Big picture, NIX could be a build option for 9front, or a branch in 9front;
something li
It seems to me that the best course, for now, is the following:
1) [Using qemu or booting the kernel on baremetal] Try and correct
Nix, in its present state, to achieve a running Nix, with 9front, for
objtype==amd64;
2) Once 1) is achieved, start cleaning (then, at this moment, the mps
stuff coul
yeah, there's a reason it is fe, and not 8, but memory fails me.
See this for details of the address hole:
https://en.wikipedia.org/wiki/X86-64
Charles may remember, but it goes back to the port they did in 2005.
On Tue, Jan 28, 2025 at 5:08 PM Ron Minnich wrote:
> btw, if you
> acid 9p
btw, if you
acid 9pc64
you can paste this right into acid
src(0xf011cdee); // dumpstack+0x10
src(0xf013d50f); // panic+0x133
src(0xf0116a3b); // KADDR+0x55
src(0xf012fe55); // sigsearch+0xc8
src(0xf012fec9); // mpsinit+0x14
src(0xf011622a); // main+0x
I'd be happier to remove the mps dependency actually. the mps is long dead.
But that's a bigger story.
On Tue, Jan 28, 2025 at 11:24 AM Paul Lalonde
wrote:
> Ah, that's the code path that sent me to QEMU.
> Vmx doesn't have any MP tables, which leads to this fault in mpsinit.
> Ron provided thi
Ah, that's the code path that sent me to QEMU.
Vmx doesn't have any MP tables, which leads to this fault in mpsinit.
Ron provided this minimal one for me, which I think we could learn from to
adapt into vmx. The hacky version of pointing the code directly at
something like this baked in didn't exc
On Tue, Jan 28, 2025 at 09:18:29AM -0800, Paul Lalonde wrote:
> ktrace can generate a stack for you from that dump. The line starting with
> "ktrace" is the command line (you might change 9k8cpu to the path to the
> kernel file in you're not in the directory where you built it).
> Then the followi
now, if you have the ktrace, you can get a stack trace, using the
first command printed in your ktrace:
ktrace 9k8cpu 0xf011cdee 0xf0105d58
and then pasting in the numbers.
see ktrace(1) for details.
Quoth tlaro...@kergis.com:
> On Tue, Jan 28, 2025 at 07:49:02AM -0800,
ktrace can generate a stack for you from that dump. The line starting with
"ktrace" is the command line (you might change 9k8cpu to the path to the
kernel file in you're not in the directory where you built it).
Then the following lines up to but not including the "cpu0: exiting" can be
dropped in
On Tue, Jan 28, 2025 at 07:49:02AM -0800, Paul Lalonde wrote:
> Do you have a stack for the assert, from the ktrace?
>
Yes, and I was wrong: it fails relatively "late" in main.c: at
mpsinit.
Here is the info (I added a bunch of print() before each function call
to know where it stumbled upon an
On Tue, Jan 28, 2025 at 07:45:02AM -0800, Paul Lalonde wrote:
> The multiboot specification says: If bit 16 in the ?flags? word is set,
> then the fields at offsets 12-28 in the Multiboot header are valid, and the
> boot loader should use them instead of the fields in the actual executable
> header
Do you have a stack for the assert, from the ktrace?
On Tue, Jan 28, 2025 at 6:09 AM wrote:
> After fixing problems leading to compiler warnings---legitimate
> warnings, but even the too short binary negated unsigned 32bits values
> promoted to 64 bits with leading bits hence 0 as mask were ha
The multiboot specification says: If bit 16 in the ‘flags’ word is set,
then the fields at offsets 12-28 in the Multiboot header are valid, and the
boot loader should use them instead of the fields in the actual executable
header to calculate where to load the OS image.
I believe they are valid in
vmx understands multiboot.
I really dislike asserts. That assert is not helpful: what is the
value of pa? What is the value of KSEG2? So if you want to start
somewhere, turn that into
if (pa>=KSEG2) panic("blah %p blah %p bla bl", pa, KSEG2); // still
one line, but actually useful output!
note th
all that does is set the lowest two bytes, which is fine.
On Tue, Jan 28, 2025 at 6:09 AM wrote:
>
> In l32p.s, the multiboot flags in the the mbi are set as
>
> $0x00010007
>
> but I don't find flags definitions relative to the higher word,
> neither in the multiboot v1 spec, nor in the enum
In l32p.s, the multiboot flags in the the mbi are set as
$0x00010007
but I don't find flags definitions relative to the higher word,
neither in the multiboot v1 spec, nor in the enum in multiboot.c. They
are all limited to the two lowest bytes.
What is the purpose of the:
$0x00010007
^
T
After fixing problems leading to compiler warnings---legitimate
warnings, but even the too short binary negated unsigned 32bits values
promoted to 64 bits with leading bits hence 0 as mask were harmless---
now I want to look at the stumbing block.
For me, under vmx, this is the assert in map.c:17:
Above all, make very sure you're not leaving a system that compiles
but will grenade once someone else tries it. You can test that via vmx
or qemu, qemu being the better choice at the moment.
On Tue, Jan 21, 2025 at 12:22 PM Ron Minnich wrote:
>
> I would advise one at a time. Big Bang changes ma
I would advise one at a time. Big Bang changes make bisection much
harder. Pick a nice short simple file you are sure you understand,
and try it.
Be sure to always see if the behavior in qemu or vmx is the same
before and after.
Small moves.
On Tue, Jan 21, 2025 at 11:54 AM wrote:
>
> What is
What is in the Nix current 386 is available, on 9front, whether under
/sys/src/9/pc or /sys/src/9/port.
Generally 386/ -> pc/ with same filename except:
386/kbd.c -> pc/devkbd.c
386/devether.c -> port/devether.c
386/random.c -> port/random.c
386/pci.c -> port/{pci,devpci}.c
What is the best Pla
That is excellent, thank you!
On Sun, 19 Jan 2025, 12:57 , wrote:
> I have started gathering notes and references about Nix, including
> (and mainly) from the mailing list, in order to put everything
> together (I will add, hopefully, original content by working on the
> code too à la Lions comm
I have started gathering notes and references about Nix, including
(and mainly) from the mailing list, in order to put everything
together (I will add, hopefully, original content by working on the
code too à la Lions commentary).
The document (CC-BY) is here:
http://notes.kergis.com/nix-os.html
What host OS? Linux is more straightforward than macOS. For macOS, the
trick (at least for me) was the right incantation of the netdev and/or
nic. This link was helpful:
https://gitlab.com/qemu-project/qemu/-/issues/465
Anyhow, on macos this is what I use; as usual the MAC address ties
things toge
I will ask someone who does that a lot.
On Tue, Jan 14, 2025 at 8:27 PM Anthony Sorace wrote:
>
> Do you (or anyone else) have a recipe for getting qemu to do a real netboot
> (as opposed to using a tiny partition to store a 9fat and netbooting from
> that)? I have tried and haven’t been able t
Do you (or anyone else) have a recipe for getting qemu to do a real netboot (as
opposed to using a tiny partition to store a 9fat and netbooting from that)? I
have tried and haven’t been able to work it out.
> On Jan 14, 2025, at 15:54, Ori Bernstein wrote:
>
> Netbooting is comfortable for
Also, a reminder: the way things improve is one yak shave at
a time. You try using the system for something, hit an issue
or limitation, and pull out the razor.
It doesn't have to happen for everything, every time, but
with enough people actually adding capabilities to the system,
things get bette
There's nothing inherently multiple core about it, and adding multicore
support is probably not even that difficult. It just needs someone who
cares to roll up their sleeves and write (probably a couple of hundred)
lines of code.
I think the trickier part will be in exposing it to the VMs, and not
Netbooting is comfortable for this -- both on emulation and on real hardware.
On Tue, 14 Jan 2025 15:08:51 -0800
Paul Lalonde wrote:
> Your email is timely.
> Yes, I just got enough init going to realize that it doesn't set up the MP
> tables.
> No now I need to figure out a flow with qemu, I gu
you should not need MP tables anyway. That is a 20-years-out-of-date
format that rarely is correct on most modern machines. ACPI is the
thing for you. 9front seems to do a good job of parsing it but, even
back in the day, plan 9 handled the MADT and friends just fine.
On Tue, Jan 14, 2025 at 3:09
Your email is timely.
Yes, I just got enough init going to realize that it doesn't set up the MP
tables.
No now I need to figure out a flow with qemu, I guess.
On Tue, Jan 14, 2025, 3:07 p.m. Stuart Morrow
wrote:
> Are you aware vmx is inherently single-core
>
> On Tue, 14 Jan 2025 at 18:01, Pau
Are you aware vmx is inherently single-core
On Tue, 14 Jan 2025 at 18:01, Paul Lalonde wrote:
>
> Credit where credit is due: this is made possible by the outstanding work the
> 9front crew have done at making a stable working distribution with all the
> bells and whistles - drawterm from my va
Credit where credit is due: this is made possible by the outstanding work
the 9front crew have done at making a stable working distribution with all
the bells and whistles - drawterm from my various desktop and
mobile devices, git for revision management, vmx for testing, and an
encouraging and use
yiyus, don't be too hard on yourself, your logos were far better than
anything anyone else did.
I had forgotten the logos entirely. I found some old list traffic and
forwarded it.
On Tue, Jan 14, 2025 at 6:09 AM Daniel Maslowski via 9fans
<9fans@9fans.net> wrote:
>
> Tracing back via the commit m
Tracing back via the commit message, that came via
https://codereview.appspot.com/5143046
On Tue, 14 Jan 2025, 10:06 , wrote:
> On Mon, Jan 13, 2025 at 10:55:30PM -0800, Ron Minnich wrote:
> > Paul has taken us a whole lot further. Be sure to do a pull. 13,000 or
> > so removed files later, NIX
> "Historical" note: David David du Colombier's 9legacy have patches
> coming from nix applied (and some reverted)
Roughly speaking, Nix is based on a version of Jim McKie's 9k from early 2011.
Jim McKie later retrieved some improvements from Nix to its own 9k tree,
especially since there was a l
On Tue, 14 Jan 2025 at 10:06, wrote:
>
> BTW, there were two "logos":
And they are horrible. We were talking about having a logo with some
kind of nixie tubes and I drafted those letters in a few minutes. Then
someone asked for a cat and I reluctantly added that "cat" in another
two minutes. And
On Mon, Jan 13, 2025 at 10:55:30PM -0800, Ron Minnich wrote:
> Paul has taken us a whole lot further. Be sure to do a pull. 13,000 or
> so removed files later, NIX is now just a small layer over a standard
> 9front distro.
>
BTW, there were two "logos":
./lib/nix_color.png
./lib/nix_red.png
(At
Paul has taken us a whole lot further. Be sure to do a pull. 13,000 or
so removed files later, NIX is now just a small layer over a standard
9front distro.
On Sun, Jan 12, 2025 at 12:07 PM Ron Minnich wrote:
>
> On Sun, Jan 12, 2025 at 11:56 AM wrote:
>
> > Note: I will work for sure some hours
On Sun, Jan 12, 2025 at 11:56 AM wrote:
> Note: I will work for sure some hours on it on week-ends, mainly on
> Sundays. I may happen to work on it supplementary to that when time
> permits---or because I'm bored at what I'm doing currently. So silence
> from me for days will not be a sign that I
Paul makes a critical point here. Just casting to make warnings go
away is almost always a bad idea. Digging into the reason for the
warning is what you want to do.
Thanks!
On Sun, Jan 12, 2025 at 11:01 AM Paul Lalonde wrote:
>
>
>
> On Sun, Jan 12, 2025 at 10:02 AM wrote:
>>
>> [I have made a
On Sun, Jan 12, 2025 at 10:59:58AM -0800, Paul Lalonde wrote:
> On Sun, Jan 12, 2025 at 10:02?AM wrote:
>
>[...]
> > Note: there are a number of warnings when compiling so my next
> > assignment will be to fix the compiler (assembler, compiler, linker)
> > warnings before tracking panics. I pref
On Sun, Jan 12, 2025 at 10:02 AM wrote:
> [I have made a first PR for some small fixes to nix/nix
> and adding a NOTES that fixes some infelicities in the
> instructions to get started]
>
Thank you! Infelicities is a very polite way to point out my poor
note-taking skills!
> Would it be possi
[I have made a first PR for some small fixes to nix/nix
and adding a NOTES that fixes some infelicities in the
instructions to get started]
I have noted that Paul Lalonde has added a script for testing the cpu
kernel with vmx.
There is also in usr/glenda/ mknixboot (John Floren) that could be
upd
We've got our second contributor!
For those looking for other things to do:
https://github.com/rminnich/nix-os/issues/8
thanks
--
9fans: 9fans
Permalink:
https://9fans.topicbox.com/groups/9fans/Ted30b22de106b2db-Mb99ee56671f0dd2afa12071f
Delivery options:
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
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
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
[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/
51 matches
Mail list logo
