Ok, I thought, what could do. So I went to my rPi 400, set up SSH for github, got Ron's nix-os repo and hit "mk". When that errored out a bunch I realized that I needed /amd64 built, so I did that. Just as painless as I remembered.
And now, I get a ways further into the build, but hit an incompatibility between the my /amd64/include/ureg.h and .../nix-os/amd64/include/ureg.h. It seems that at some point since the NIX code was written someone decided that the program counter should be called pc instead of ip. Or else, I'm approaching this all wrong, and Ron can shed some light on how I should be proceeding. Paul On Tue, Jan 7, 2025 at 4:01 PM Ron Minnich <rminn...@p9f.org> wrote: > I found the original 2011 paper, which was a sandia report, from may > 2011. It's a modification of the original proposal, which I no longer > have; but it is a good summary of where we were at the end of my visit > in May. > > This is interesting: "We have changed a surprisingly small amount of > code at this point. > There are about 400 lines of new > assembler source, about 80 lines of platform independent C source, and > about 350 lines of AMD64 C > source code. To this, we have to add a few extra source lines in the > start-up code, system call, and trap han- > dlers. This implementation is being both developed and tested only in > the AMD64 architecture." > > I uploaded it to the Plan 9 foundation shared drive: > > https://drive.google.com/file/d/1F41_4MFpio3UsnxOpTJBiypUrHjkinL-/view?usp=share_link > > On Tue, Jan 7, 2025 at 10:18 AM <tlaro...@kergis.com> wrote: > > > > On Tue, Jan 07, 2025 at 09:20:06AM -0800, Ron Minnich wrote: > > > > > > Why NIX? > > > > > > If you think about it, timesharing is designed for a world where cores > > > are scarce. But on a machine with hundreds of cores, running Plan 9, > > > there are < 100 processes. We can assign a core to each process, and > > > let those processes own the core until they are done. This might be a > > > useful simplification, it might not, but it's something. > > > > > > I did run some standard HPC benchmarks on NIX ACs and the results were > > > good. I was always curious how it would work if we had those > > > multi-hundred-core machines Intel and IBM and others were telling us > > > about in 2011. Now that we have them, it would be interesting to try. > > > > As said previously, I will start wandering and stumbling upon problems > > this week-end---I'm a toddler in the area, so it's the way to learn to > > walk. > > > > But this brief summary highlight a solution and questions > > that are, IMHO, valid questions: remember the "war" between > > "micro-kernels" and "monolithic kernels"? In Unix, the kernel is not a > > separate process (well: there are "administrative" processes, > > scheduler and pager but...) but part of the applications. This is also > > why it is efficient compared to "message passing" micro-kernels that > > are not "near" enough the hardware---so inefficient that, for > > ideologic purposes, some have rewritten "micro-kernels" in assembly to > > improve the result... > > > > But multiple cores (and even in the smaller machines nowadays, you > > find two) present another mean of articulation of the OS code (the > > MMU is central for me in the whole picture: not move the data > > around, but change the view of the shared data per core). The question > > is at least certainly worth asking. > > > > -- > > Thierry Laronde <tlaronde +AT+ kergis +dot+ com> > > http://www.kergis.com/ > > http://kertex.kergis.com/ > > Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T7692a612f26c8ec5-M4d83bfc77a21f3e907bcfc2e Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
