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
Permalink:
https://9fans.topicbox.com/groups/9fans/T7692a612f26c8ec5-M168534a1edfe40b2e2ddc134
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
nixdiff
Description: Binary data
mkfile
Description: Binary data
