NIX is moving forward, thank you paul!
The branch is called regen, we have our first commit in many years.
Please take a look. If you submit a PR, please add a signed-off-by:
line.
thanks
On Tue, Jan 7, 2025 at 10:01 PM Ron Minnich <rminn...@p9f.org> wrote:
>
> so for work like this, my motto is commit early, commit often, to a
> branch we can always drop later. no harm. It's easier (for me anyway)
> than shuffling patches around in email.
>
> I'm happy to accept a pull request against rminnich/nix-os, , let's
> call the branch regen.
>
> thanks
>
> On Tue, Jan 7, 2025 at 9:52 PM Paul Lalonde <paul.a.lalo...@gmail.com> wrote:
> >
> > As you say, Ron.
> >
> > First, here's my nix script, such as it is, cribbed from the old nix one.
> > It has holes, guaranteed. Also, I went and pulled in a "user" directory,
> > just for old habits dying hard. Yes, I still use glenda on this old
> > terminal. Call me names for it.
> >
> > #!/bin/rc
> >
> > unmount /sys/include >[2]/dev/null
> >
> > unmount /sys/src/libc >[2]/dev/null
> >
> > bind -b /usr/glenda/nix-os/sys/include /sys/include
> >
> > bind -c /usr/glenda/nix-os/sys/src/libc /sys/src/libc
> >
> > cd /usr/glenda/nix-os/sys
> >
> > for(d in man/*){
> >
> > unmount /sys/$d >[2]/dev/null
> >
> > bind -b $d /sys/$d
> >
> > }
> >
> > exit ''
> >
> >
> > My terminal is a pi 400, so I had to build out the /amd64 tree,
> > objtype=arm64. I'll assume folks are clever enough to do this, or to use
> > an amd64 terminal or cpu to do this work.
> >
> >
> > Then mk your heart out. The main pain points are ulong parameters that are
> > now usize in 9front, and the renaming of Ureg.ip to Ureg.pc. These changes
> > appear limited to
> >
> > M amd64/include/ureg.h
> >
> > M sys/include/libc.h
> >
> > M sys/src/boot/pc/lib.h
> >
> > M sys/src/nix/boot/nopsession.c
> >
> > M sys/src/nix/k10/acore.c
> >
> > M sys/src/nix/k10/fpu.c
> >
> > M sys/src/nix/k10/sipi.h
> >
> > M sys/src/nix/k10/syscall.c
> >
> > M sys/src/nix/k10/trap.c
> >
> > M sys/src/nix/port/lib.h
> >
> > M sys/src/nix/port/portfns.h
> >
> > The diffs are attached. I don't want to commit a branch because as I said,
> > I don't think my bind mappings are entirely correct, though I'm seeing many
> > fewer crossed wires now.
> > Attached is the (trivial) mkfile I built for nix-os/sys/nix/boot which
> > *almost* makes a full build happen. parseipmask has gained a v4 parameter
> > in 9front, which means the fix there needs actual analysis. qsort is
> > somehow also complaining, possibly indicating I'm pulling the wrong header
> > for it, indicating a problem in my bind script.
> >
> > This feels completely surmountable.
> >
> >
> > Paul
> >
> >
> > On Tue, Jan 7, 2025 at 9:29 PM Ron Minnich <rminn...@p9f.org> wrote:
> >>
> >> 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 / see discussions + participants + delivery options Permalink
------------------------------------------
9fans: 9fans
Permalink:
https://9fans.topicbox.com/groups/9fans/T7692a612f26c8ec5-M61a12703b44240d058a66a56
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
