Fantastic!
Ron, to make it easier, you can set the regen branch as the new default
branch in the repo settings on GitHub, so people don't accidentally file
against master.
On Thu, 9 Jan 2025, 23:22 Ron Minnich, <rminn...@p9f.org> wrote:
> 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-Mb71d11397ae3ece9bfa9087b
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
