Thanks, Daniel, done.
On Thu, Jan 9, 2025 at 5:59 PM Daniel Maslowski via 9fans
<9fans@9fans.net> wrote:
>
> 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 / see discussions + participants + delivery options Permalink
------------------------------------------
9fans: 9fans
Permalink:
https://9fans.topicbox.com/groups/9fans/T7692a612f26c8ec5-M1548153856197d17c27a6fc3
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
