WOW! Paul got it to build.
git/clone g...@github.com:rminnich/nix-os
git/branch -b origin/regen -n regen
cd sys/src/nix
# HEY ANYONE! WANT TO FIX THIS!
rc -x nix # set the x bits?
# make it so it does not have to be in $home/nix-os?
cd boot
mk
cd ../k10
mk
# it may seem like it hangs, it's actually waiting for your nvram key.
# HEY ANYONE! the prompt for nvram gets buried in output. Want to fix this?
vmx 9k8cpu # HEY ANYONE! vmx thinks the multiboot header in 9k8cpu is
wrong, but it's not. This is an easy one, Look at the multiboot header
in l32p.s
# and see why vmx does not like it.
Or just netboot a cpu server with 9k8cpu
Note we decided to leave a few things for people to take a try at
fixing. These are great little exercises. Learn to use git, learn a
workflow, building a kernel, etc. etc.
contributing:
The github workflow is to fork github.com/rminnich/nix-os, checkout a
branch based on regen, hack hack, commit -s, push to your branch, that
will make a pull request.
Very standard stuff, we don't know how to make it all work with 9front git yet.
Questions? Put them here, and thanks in advance.
ron
On Wed, Jan 8, 2025 at 4:19 PM Ron Minnich <rminn...@p9f.org> wrote:
>
> 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-Mc84faae8239e0743d68adfc2
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
