if you can document your steps, then others can stand on your shoulders, possibly, and we can all move forward?
On Tue, Jan 7, 2025 at 9:08 PM Paul Lalonde <paul.a.lalo...@gmail.com> wrote: > > 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 / see discussions + participants + delivery options Permalink ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T7692a612f26c8ec5-M7bc8a8dfe29d63e01303d727 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
