Ok, not a bad first day poking at it. I have a growing (but not ready) new nix script to pull the right pieces over top of my build environment. I have a near-complete build, but with hazards: 9front has evolved in a number of places with many ulong parameters becoming usize. I have a list of those spots, but now they need to be examined for over/underflow. The last puzzle of the day is nix-os/sys/src/nix/boot. The repo includes the libboot.a6 binary, some source files that match the symbols, and no mkfile. Attempting to build also shows some 9front auth changes that need to be incorporated into doauthenticate.c, calls to convS2M and convM2S that now need buffer length parameters, and the phasing of Tnop out 9p? Nothing at all insurmountable.
Not too daunting. Next time I have a few moments I'll do a more principled pass on the nix script so I can share it. I didn't understand enough when I first started updating it. Paul On Tue, Jan 7, 2025 at 6:58 PM Ron Minnich <rminn...@p9f.org> wrote: > if you look at the first_commit branch, you'll see a sys/src/nix/nix > script, which sets up some binds. > > What we did, before building nix, on plan 9, in 2011, was a set of > binds to get the right things such as /sys/include and so on. > > This won't be just a 'mk and it builds'. There's 13 years of bitrot. > I expect it will be strategic changes, and in the end they won't be > all that many lines of code, but there will be some tricky stuff. > > Best ot take it slow, when you hit an issue, ruminate it on for a day > or two, then look again. Otherwise you'll just get frustrated (I have > ...) But before you make any change, be very sure you know WHY you're > doing it, not just that 'it got me past that mk error.' > > Bring issues to the list and, if you want, keep a running doc to which > others can contribute: what you did, what you ran into, what a fix > might be. The old saying; "if you don't write it down it didn't > happen" > > But this is the kind of thing you take slowly and carefully, otherwise > it's total misery. > > ron > > On Tue, Jan 7, 2025 at 5:34 PM Paul Lalonde <paul.a.lalo...@gmail.com> > wrote: > > > > And a bit more digging. Yes, I'm clearly doing this wrong. In building > nix-os/sys/src/k10/trap.c it should absolutely be using the Tos structure > from nix, not the one in the host system. > > > > How do I re-root this correctly for this build? > > > > Paul > > > > On Tue, Jan 7, 2025 at 4:47 PM Paul Lalonde <paul.a.lalo...@gmail.com> > wrote: > >> > >> 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 / see discussions + participants + delivery options > Permalink ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T7692a612f26c8ec5-M17f91ce3175aeaa0be41937d Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
