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-M3769343bc21b9d2e2f27b00c
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
