[9fans] NIX this evening

[9fans] NIX this evening

[ron minnich]

[-- Attachment #1: Type: text/plain, Size: 670 bytes --]

I've caught NIX up to 9front tip of tree. All works.

I've backed out one set of changes, to fpu.c.

There's a lingering problem: in the original NIX, at the end of system
calls, we had a function, fakeretfromsyscall, which we called on the tcore,
as we exited back out to the acore.

We've not brought that back in yet, and that is actually why I had to add
the poperror in syscall().

So this needs a few more eyes and cleanup.

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tc110fef89c1cd4af-M50e327199775dfbd8e75345a
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 1243 bytes --]

Re: [9fans] NIX this evening

[Lucio De Re]

[-- Attachment #1: Type: text/plain, Size: 1452 bytes --]


On 2025/03/08 18:43, Jacob Moody wrote:
> Or maybe you start from old
> nix and bring in the parts of 9front that you'd need in order to get things running
> on the system you want.

That's a tedious, expensive, but in my opinion wise move. It's also 
optional, because clearly 9front is not going to benefit (much) from the 
efforts. But I'm willing to assist, although right now my concentration 
is on more urgent issues of my own. Which means that the chasm between 
what I know about 9legacy, the tiny bit of 9front I am familiar with and 
what I need to know to be of help in this, will only grow further.

But what I see happening gives me hope. I have observed the divergence 
between 9legacy and 9front and my hope is that progress will lead to the 
user of Plan 9 in its few flavours (a) being able to choose the one best 
suited to their situation and (b) being able to switch from one flavour 
to another with effort in the same league as picking one of the *BSDs 
for a similar purpose.

Posterity will eventually distill the essence of Plan 9 into the product 
it is destined to become, be it academic, research related or even 
practical. If there is a posterity, I suppose.

Lucio.

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tc82cdeb7e597b9d2-M136b924a344b794e5f1f1ccd
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 2246 bytes --]

Re: [9fans] NIX this evening

[ron minnich]

[-- Attachment #1: Type: text/plain, Size: 2476 bytes --]

From my point of view, there's no wrong moves here. Our goal is to learn. I
learned a lot just bringing it all back to life, and I am sure Thierry will
learn a lot with his approach. I look forward to seeing what he does.

Folks, I'm serious, there are lots of simple things to do, and there are
hard things to do;  all contributions are welcome, and it's a good way to
get into kernel work, since it is in the end a very minor set of changes.
As the performance measurement shows, it can have a very large impact.

ron

On Sat, Mar 8, 2025 at 10:06 AM <tlaronde@kergis.com> wrote:

> On Sat, Mar 08, 2025 at 10:43:46AM -0600, Jacob Moody wrote:
> > > On 3/8/25 03:03, tlaronde@kergis.com wrote:
> > >
> > > I will start from the subset isolated (due to the pace of Ron and
> > > Paul, looong ago now; at least two weeks...), having the current
> > > state as reference, but trying to get things working against 9legacy.
> > > But using binds and explicit mkfile rules to reach the correct source
> > > when there are same filenames between Nix and the host distribution.
> >
> > Sure, I wish you the best of luck with getting nix rebased on top of
> > 9legacy. I will warn you however that you'll need more conceptual
> understanding
> > of what the code is doing instead of just working based on filenames in
> order to
> > undo the 10+ years of changes that 9front has done. Or maybe you start
> from old
> > nix and bring in the parts of 9front that you'd need in order to get
> things running
> > on the system you want.
> 
> This is what I plan to do: I will start from "original" Nix (but the
> needle extracted from the hay stack, and reverting the very early
> changes made by Paul about qsort etc.), and then will try to first make
> it compile with 9legacy, fixing things having the obvious help of the
> changes made by Ron and Paul (if the problems are similar, of course...),
> before trying to "update" it with modifications done in the master
> repository (Ron's git repository).
> --
> 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
Permalink: https://9fans.topicbox.com/groups/9fans/Tc82cdeb7e597b9d2-M03ded74797b98662cb119d02
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 4357 bytes --]

Re: [9fans] NIX this evening

[tlaronde]

On Sat, Mar 08, 2025 at 10:43:46AM -0600, Jacob Moody wrote:
> > On 3/8/25 03:03, tlaronde@kergis.com wrote:
> > 
> > I will start from the subset isolated (due to the pace of Ron and
> > Paul, looong ago now; at least two weeks...), having the current
> > state as reference, but trying to get things working against 9legacy.
> > But using binds and explicit mkfile rules to reach the correct source
> > when there are same filenames between Nix and the host distribution.
> 
> Sure, I wish you the best of luck with getting nix rebased on top of
> 9legacy. I will warn you however that you'll need more conceptual understanding
> of what the code is doing instead of just working based on filenames in order to
> undo the 10+ years of changes that 9front has done. Or maybe you start from old
> nix and bring in the parts of 9front that you'd need in order to get things running
> on the system you want.

This is what I plan to do: I will start from "original" Nix (but the
needle extracted from the hay stack, and reverting the very early
changes made by Paul about qsort etc.), and then will try to first make
it compile with 9legacy, fixing things having the obvious help of the
changes made by Ron and Paul (if the problems are similar, of course...),
before trying to "update" it with modifications done in the master
repository (Ron's git repository).
-- 
        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
Permalink: https://9fans.topicbox.com/groups/9fans/Tc82cdeb7e597b9d2-M0c0b3a376d499f35920fe044
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] NIX this evening

[Jacob Moody]

On 3/8/25 03:03, tlaronde@kergis.com wrote:
> On Fri, Mar 07, 2025 at 01:09:30PM -0600, Jacob Moody wrote:
>> On 3/7/25 06:10, tlaronde@kergis.com wrote:
>>> On Thu, Mar 06, 2025 at 03:47:42PM -0800, ron minnich wrote:
>>>> thanks, Jacob.
>>>> I'm going to keep at it, and your rebase has now made it much easier to
>>>> keep up.
>>>>
>>>> In the usual manner of such things, I think now that we figured out that we
>>>> can make it work, it's time to toss a lot of those commits away, and get to
>>>> something a lot less messy. There's where others can help.
>>>>
>>>
>>> May I ask why you didn't keep the small nix set of files that you (I
>>> mean you Ron, and Paul) have finally selected?
>>>
>>> It seems to me that having, a la 9legacy (that has sys/src/9 and
>>> sys/src/9k), a sys/src/nix, that is having a git repo just nix, with a
>>> branch 9front (this flavor has just to be binded in 9front
>>> sys/src/nix) and, why not, a 9legacy (this flavor has just to binded
>>> in 9legacy sys/src/nix) would avoid the pain, for now, to have to
>>> update when 9front is moving and will have the supplementary benefit
>>> of showing what is Nix.
>>
>> The main issue is that nix is not self contained, presumably the nix kernel
>> wants access to 9front's drivers, multiboot, nvme support etc.
> 
> 
> Just for the sake of argument: This can be solved by the order of
> binding or in the mkfiles, by explicit rules to select the correct
> file when there are same filenames.

This doesn't solve the issue that I pointed out. The files you are binding
have to come from somewhere. You can either track them in the repository
(either by having your commits on top of the whole system, or vendored in)
or you can rely on the local user's machine to have the right version.

The goal of tracking the dependencies with the project itself is to make
sure the rest of the code you require to build your project keeps working
no matter the current state of someone's machine. Even if you don't track
the other files in the repo, you still have those dependencies. If 9front
updates something with the Proc struct, you don't want the nix repo to break
in a way that is not immediately obvious to those managing the project right?

The core of it is that nix relies on other parts of the kernel, you can either
choose to bake those assumptions in to the repo and track them with the nix project
or you can ignore them and deal with breakages depending on whatever state the
user's machine is in.

>> [...] 
>> Also to be frank I would find it highly unlikely that a single repository would work for
>> both 9legacy and 9front, [...]
> 
> This is not what I wrote: a Nix repository, with two distinct branches,
> not the same, because there are indeed divergences. But in 9legacy,
> there is also the "memory" of 9k, with evolutions about memory
> allocation done after 2011 that need to be evaluated (and apparently,
> Nemo has done work, after 2011, on memory allocation for
> Nix too). So, later, there will have to be some weaving to be done,
> with some jigsaw puzzles pieces scattered here and there to perhaps
> put back in the picture.

I apologize for my misreading.

> 
> Since it will take weeks before I can make any significant code
> contributions to Nix (since I'm at the moment largely out of my
> depth in the kernel aera), I will document things --- because I
> have found it a great way to learn to "pretend teaching" a subject;
> when trying to explain, questions arise about which you never
> thought when simply reading an expos\'e and more than once something
> I was about to describe as "obvious" with a waving hand was not
> obvious at all, sometimes generally true but could in some contexts
> be false, and even sometimes definitively wrong).
> 
> I will start from the subset isolated (due to the pace of Ron and
> Paul, looong ago now; at least two weeks...), having the current
> state as reference, but trying to get things working against 9legacy.
> But using binds and explicit mkfile rules to reach the correct source
> when there are same filenames between Nix and the host distribution.

Sure, I wish you the best of luck with getting nix rebased on top of
9legacy. I will warn you however that you'll need more conceptual understanding
of what the code is doing instead of just working based on filenames in order to
undo the 10+ years of changes that 9front has done. Or maybe you start from old
nix and bring in the parts of 9front that you'd need in order to get things running
on the system you want.

> 
> The differences will be my Ariadne thread in the kernel maze. And I
> expect it will be quite instructive to compare what is done
> differently in the amended original 9legacy and in 9front.

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tc82cdeb7e597b9d2-M117b8c11e875c618c33ff202
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] NIX this evening

[tlaronde]

On Fri, Mar 07, 2025 at 01:09:30PM -0600, Jacob Moody wrote:
> On 3/7/25 06:10, tlaronde@kergis.com wrote:
> > On Thu, Mar 06, 2025 at 03:47:42PM -0800, ron minnich wrote:
> >> thanks, Jacob.
> >> I'm going to keep at it, and your rebase has now made it much easier to
> >> keep up.
> >>
> >> In the usual manner of such things, I think now that we figured out that we
> >> can make it work, it's time to toss a lot of those commits away, and get to
> >> something a lot less messy. There's where others can help.
> >>
> > 
> > May I ask why you didn't keep the small nix set of files that you (I
> > mean you Ron, and Paul) have finally selected?
> > 
> > It seems to me that having, a la 9legacy (that has sys/src/9 and
> > sys/src/9k), a sys/src/nix, that is having a git repo just nix, with a
> > branch 9front (this flavor has just to be binded in 9front
> > sys/src/nix) and, why not, a 9legacy (this flavor has just to binded
> > in 9legacy sys/src/nix) would avoid the pain, for now, to have to
> > update when 9front is moving and will have the supplementary benefit
> > of showing what is Nix.
> 
> The main issue is that nix is not self contained, presumably the nix kernel
> wants access to 9front's drivers, multiboot, nvme support etc.


Just for the sake of argument: This can be solved by the order of
binding or in the mkfiles, by explicit rules to select the correct
file when there are same filenames.

> [...] 
> Also to be frank I would find it highly unlikely that a single repository would work for
> both 9legacy and 9front, [...]

This is not what I wrote: a Nix repository, with two distinct branches,
not the same, because there are indeed divergences. But in 9legacy,
there is also the "memory" of 9k, with evolutions about memory
allocation done after 2011 that need to be evaluated (and apparently,
Nemo has done work, after 2011, on memory allocation for
Nix too). So, later, there will have to be some weaving to be done,
with some jigsaw puzzles pieces scattered here and there to perhaps
put back in the picture.

Since it will take weeks before I can make any significant code
contributions to Nix (since I'm at the moment largely out of my
depth in the kernel aera), I will document things --- because I
have found it a great way to learn to "pretend teaching" a subject;
when trying to explain, questions arise about which you never
thought when simply reading an expos\'e and more than once something
I was about to describe as "obvious" with a waving hand was not
obvious at all, sometimes generally true but could in some contexts
be false, and even sometimes definitively wrong).

I will start from the subset isolated (due to the pace of Ron and
Paul, looong ago now; at least two weeks...), having the current
state as reference, but trying to get things working against 9legacy.
But using binds and explicit mkfile rules to reach the correct source
when there are same filenames between Nix and the host distribution.

The differences will be my Ariadne thread in the kernel maze. And I
expect it will be quite instructive to compare what is done
differently in the amended original 9legacy and in 9front.
-- 
        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
Permalink: https://9fans.topicbox.com/groups/9fans/Tc82cdeb7e597b9d2-Mc1dcddff71083fc4077d6b8f
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] NIX this evening

[ron minnich]

[-- Attachment #1: Type: text/plain, Size: 15009 bytes --]

It's not like cgroups at all.

Consider a system with lots of CPUs. Kernels, as they boot, will allocate
all those CPUs for their own use. These CPUs will assigned to different
processes over time, or be assigned to running kernel processes. Interrupts
will be scheduled across this set of cores, with  one goal being to
distribute them in some sort of fair fashion.

These are time sharing cores (TC).

NIX adds a new class of cores, called Application cores. An Application
core does not get involved in any of this activity. Instead, they wait to
be assigned work to do. Once assigned that work, they run it until the work
exits. The work will not be interrupted; indeed, interrupts are disabled.
The ACs run a very small for loop which waits on work to do and does it.

It's very, very different from cgroups, which are really just resource
consumption definitions.

thanks

On Fri, Mar 7, 2025 at 12:25 PM Clout Tolstoy <tolstoyclout@gmail.com>
wrote:

> Forgive the layman question but is NIX somewhat similar to cgroups in the
> Linux kernel?
> On Fri, Mar 7, 2025, 6:08 AM <tlaronde@kergis.com> wrote:
>
>> On Thu, Mar 06, 2025 at 03:47:42PM -0800, ron minnich wrote:
>> > thanks, Jacob.
>> > I'm going to keep at it, and your rebase has now made it much easier to
>> > keep up.
>> >
>> > In the usual manner of such things, I think now that we figured out
>> that we
>> > can make it work, it's time to toss a lot of those commits away, and
>> get to
>> > something a lot less messy. There's where others can help.
>> >
>>
>> May I ask why you didn't keep the small nix set of files that you (I
>> mean you Ron, and Paul) have finally selected?
>>
>> It seems to me that having, a la 9legacy (that has sys/src/9 and
>> sys/src/9k), a sys/src/nix, that is having a git repo just nix, with a
>> branch 9front (this flavor has just to be binded in 9front
>> sys/src/nix) and, why not, a 9legacy (this flavor has just to binded
>> in 9legacy sys/src/nix) would avoid the pain, for now, to have to
>> update when 9front is moving and will have the supplementary benefit
>> of showing what is Nix.
>>
>> IMHO, it seems it will be far more easier for people wanting to
>> contribute to have just the Nix set of added or modified files in one
>> directory and to let you and others joining focus on Nix related
>> things without to have to bother merging or cherry picking
>> "surroundings".
>>
>> Also a nix/nix for scaffolding scripts (building a namespace---in the
>> case of a dedicated nix/ dir---, testing and so on).
>>
>> FWIW.
>>
>> T. Laronde
>>
>> > ron
>> >
>> > On Thu, Mar 6, 2025 at 3:38?PM Jacob Moody <moody@posixcafe.org> wrote:
>> >
>> > > On 3/6/25 15:07, ron minnich wrote:
>> > > > Jacob re the rebase, thank you, it works in qemu and on my t420.
>> > > >
>> > > > I'm thinking to just set my 9front head to what you've done, push
>> it to
>> > > my fork, and proceed from there. Do you see any reason not to?
>> > >
>> > > Sure by all means.
>> > >
>> > > >
>> > > > Where, ultimately, might we want NIX to land?
>> > > >
>> > > > I need to start turning the dial down on debug prints, to start.
>> > >
>> > > I think it depends on what the goals are here, I assume you're
>> somewhat
>> > > interested in having a conversation about getting
>> > > nix in to 9front, so I'll start from there. Here's what I would
>> suggest as
>> > > the path forward for that and some followup questions.
>> > >
>> > > 1. You'll need to squash your changes in to a smaller organization of
>> > > patches that can be reviewed, the current commit list is a bit messy
>> > >         and does not follow our conventions for commit messages.
>> > >
>> > > 2. You'll need to make a case as to what the practical benefits are
>> from
>> > > having this capability, it seems like you've gotten somewhere with
>> > >         the ftq benchmarks, which is great, but you'll need to put
>> things
>> > > in terms of practical benefit. What is a program on the system which
>> > >         would benefit from having a core exclusive to itself? How can
>> we
>> > > prove that? Adding stuff to the Proc struct has a high impact and
>> typically
>> > >         should be accompanied by a decently useful addition.
>> > >
>> > > 3. Everything right now is specific to pc64, and I think if this is a
>> > > general capability going forward, we're going to need this on the
>> other
>> > >         architectures that we support. At the very least arm64. I
>> don't
>> > > know if I would call this a requirement for getting nix merged but
>> > >         it should be something that would be a close goal following an
>> > > initial merge if not.
>> > >
>> > > 4. For now at least, I would suggest removing the debug prints. The
>> > > question regarding on how to go forward with debug prints in general
>> is
>> > >         a good question, and something we can discuss but the
>> discussion
>> > > of nix and the discussion on debug prints are two separate discussions
>> > >         (and ideally two separate patches). To this end I would
>> perhaps be
>> > > partial to having some sort of additional file (/dev/kdebug?) that
>> > >         would serve some ring buffer that can be enabled with a write
>> and
>> > > would serve the results. (Think /net/log). This would be a bit more
>> costly
>> > >         compared to being able to #ifdef them out but I think in this
>> case
>> > > it may be worth it.
>> > >
>> > > Once you feel like you've got an organized set of diffs, the code
>> cleaned
>> > > up, and some sort of data to make an argument I would say post it
>> over on
>> > > the 9front list. Or perhaps pop your head in on irc or one of our
>> jitsi
>> > > calls to talk it out in real time.
>> > >
>> > > In general, and in particular with large impact changes like this,
>> expect
>> > > a lot of discussion on implementation, organization, and interface
>> for these
>> > > patches if you want to go forward with arguing for their inclusion in
>> > > 9front. What I tend to do is regularly review the "big diff" against
>> > > upstream
>> > > and check that extra stuff hasn't snuck in.
>> > >
>> > > Stuff like:
>> > >
>> > >
>> https://github.com/majiru/9front/compare/front...nix#diff-3530d7439c30d8e9125572d4c7eb0f42ca56b6adb8b069c7ce08c023c6067e48
>> > >
>> > >
>> https://github.com/majiru/9front/compare/front...nix#diff-4fac6b341748f453f31ecd0d99acc52e6069bef0d85f51200d3a498f31acc9a0R20
>> > >
>> > >
>> https://github.com/majiru/9front/compare/front...nix#diff-4fac6b341748f453f31ecd0d99acc52e6069bef0d85f51200d3a498f31acc9a0R43
>> > >
>> > > You've got some files which are lacking trailing newlines at the very
>> end
>> > > of the file as well that you'll want to clean up.
>> > >
>> > > The short of it is now that you've got things to a working state, I'd
>> > > start cleaning stuff up, and start asking people to review
>> > > these cleaned up version to get feedback on the implementation. If you
>> > > agree that this is where you're at with this.
>> > >
>> > > >
>> > > > on the original NIX, as we were in an HPC mindset, we made the only
>> TC
>> > > core 0, and all other cores ACs.
>> > > >
>> > > > I am wondering about a boot-time variable, such that, if not set,
>> there
>> > > are no ACs; and, if set, it means "all cores from this number up" are
>> ACs.
>> > >
>> > > Some sort of plan9.ini setting, maybe just a list of core numbers
>> that you
>> > > want to be AC's? I'm thinking something that would allow you to set a
>> > > specific
>> > > list of cores. If for example your intel chip makes every odd numbered
>> > > chip an E core, you may want to interleave them.
>> > >
>> > > >
>> > > > Also ... re debugging ... do you have some way of controlling, on a
>> > > fairly fine basis, when and how to print debug messages?
>> > >
>> > > I ended up addressing this in the above list.
>> > >
>> > > >
>> > > > jmk had done something for 9k, which we also used on blue gene and
>> then
>> > > NIX, not sure when (2005? Charles, do you recall?) that worked like
>> this:
>> > > > in, e.g., pc64, you have a dbgflg section. You could define a single
>> > > letter for a subsystem. So, e.g.,
>> > > > dbgflg
>> > > >     acore 'c'
>> > > >     tcore 'c'
>> > > >     ioapic 'I'
>> > > >
>> > > > There was a macro, DBG: DBG(...)
>> > > > DBG acts like print if the dbgflg is set FOR THAT FILE.
>> > > >
>> > > > This all gets munged by awk and friends such that each .c can check
>> > > dbgflg[_DBGC_] to see whether debug prints are enabled. That's all
>> DBG is.
>> > > >
>> > > > You can make all debugging go away by defining a variable to be 0
>> and
>> > > letting the linker do the elision (that's one variant of the
>> definition of
>> > > the macros, see
>> > >
>> https://github.com/rminnich/nix-os/blob/regen/sys/src/nix/k10/dat.h#L409
>> <
>> https://github.com/rminnich/nix-os/blob/regen/sys/src/nix/k10/dat.h#L409
>> >.
>> > > Note a typical jmk comment: horrid :-)
>> > > >
>> > > > long story short, you could set debug flags in the command line or
>> in
>> > > plan9.ini, and DBG would be enabled or not in the various subsystems.
>> It
>> > > was a very easy way to turn debug on and off on a per-boot-time basis.
>> > > >
>> > > > It was nice, but it seems to have been lost in most plan 9 kernels.
>> > > >
>> > > > What do people do now in legacy/9front/whatever?
>> > > >
>> > > > Finally, for those trying to build NIX, no binds needed. git clone
>> the
>> > > repo of your choice, check out the branch, cd sys/src/9/pc64, and mk.
>> > > >
>> > > > Finally, ... coders welcome. The level of things to do is WAY less
>> > > daunting now that we are sort of working, and part of the goal of
>> bringing
>> > > NIX back is to suck people in to working on the kernel.
>> > > >
>> > > > thanks
>> > > >
>> > > >
>> > > > On Wed, Mar 5, 2025 at 1:57?PM <tlaronde@kergis.com <mailto:
>> > > tlaronde@kergis.com>> wrote:
>> > > >
>> > > >     On Wed, Mar 05, 2025 at 09:16:57PM +0100, tlaronde@kergis.com
>> > > <mailto:tlaronde@kergis.com> wrote:
>> > > >     > On Wed, Mar 05, 2025 at 07:11:02PM +0100, tlaronde@kergis.com
>> > > <mailto:tlaronde@kergis.com> wrote:
>> > > >     > > I need to update the documentation about the building (one
>> needs
>> > > to
>> > > >     > > bind above the 9front hier, but also to get
>> plan9front/firmware,
>> > > and
>> > > >     > > to build and install brekky).
>> > > >     > >
>> > > >     > > But it also uses ftq.
>> > > >     >
>> > > >     > BTW, execac is missing also.
>> > > >
>> > > >     No: here ./sys/src/cmd/execac.c; needs simply to be compiled.
>> > > >
>> > > >     > >
>> > > >     > > If I'm not mistaken, the git master has an unchanged mkfile
>> > > relating
>> > > >     > > to several flavors (ftq{15,31,63}) but is marked as broken.
>> > > >     > >
>> > > >     > > Do you compile it under APE?
>> > > >     > >
>> > > >     > > On Mon, Mar 03, 2025 at 07:44:47PM -0800, ron minnich wrote:
>> > > >     > > > I am now able to run the HPC FTQ benchmark and get
>> results,
>> > > first time
>> > > >     > > > since 2011.
>> > > >     > > >
>> > > >     > > > The results are very, very good on my T420. Next step,
>> see how
>> > > it goes on a
>> > > >     > > > server class machine.
>> > > >     > > >
>> > > >     > > > If anyone wants to help out, the rebase would be most
>> welcome,
>> > > as would
>> > > >     > > > testing of your choice.
>> > > >     > > >
>> > > >     > > > Taking a trap on an AC still does not work. I get around
>> that
>> > > by making
>> > > >     > > > sure traps won't happen but ... would be nice to fix it.
>> > > >     > > >
>> > > >     > > > In NIX, we had a new rfork type which would let a process
>> flip
>> > > itself onto
>> > > >     > > > an AC; it would be useful to bring that over.
>> > > >     > > >
>> > > >     > > > Lots to do, whoever wants to help, we're open for
>> business.
>> > > >     > >
>> > > >     > > --
>> > > >     > > Thierry Laronde <tlaronde +AT+ kergis +dot+ com>
>> > > >     > >              http://www.kergis.com/ <http://www.kergis.com/
>> > > >     > >             http://kertex.kergis.com/ <
>> http://kertex.kergis.com/
>> > > >     > > Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95
>> 6006
>> > > F40C
>> > > >     >
>> > > >     > --
>> > > >     >         Thierry Laronde <tlaronde +AT+ kergis +dot+ com>
>> > > >     >                      http://www.kergis.com/ <
>> > > http://www.kergis.com/>
>> > > >     >                     http://kertex.kergis.com/ <
>> > > http://kertex.kergis.com/>
>> > > >     > Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95
>> 6006
>> > > F40C
>> > > >
>> > > >     --
>> > > >             Thierry Laronde <tlaronde +AT+ kergis +dot+ com>
>> > > >                          http://www.kergis.com/ <
>> http://www.kergis.com/>
>> > > >                         http://kertex.kergis.com/ <
>> > > http://kertex.kergis.com/>
>> > > >     Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006
>> F40C
>> > > >
>> > > >     ------------------------------------------
>> > > >     9fans: 9fans
>> > > >     Permalink:
>> https://9fans.topicbox.com/groups/9fans/Tc82cdeb7e597b9d2-M39192ec6eef3979dd0ea7579
>> > > <
>> > >
>> https://9fans.topicbox.com/groups/9fans/Tc82cdeb7e597b9d2-M39192ec6eef3979dd0ea7579
>> > > >
>> > > >     Delivery options:
>> > > https://9fans.topicbox.com/groups/9fans/subscription <
>> > > https://9fans.topicbox.com/groups/9fans/subscription>
>> > > >
>> > > > *9fans <https://9fans.topicbox.com/latest>* / 9fans / see
>> discussions <
>> > > https://9fans.topicbox.com/groups/9fans> + participants <
>> > > https://9fans.topicbox.com/groups/9fans/members> + delivery options <
>> > > https://9fans.topicbox.com/groups/9fans/subscription> Permalink <
>> > >
>> https://9fans.topicbox.com/groups/9fans/Tc82cdeb7e597b9d2-M90f81cabe64c4d4bcdcfd5c7
>> 
>> --
>> 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 <https://9fans.topicbox.com/latest>* / 9fans / see discussions
> <https://9fans.topicbox.com/groups/9fans> + participants
> <https://9fans.topicbox.com/groups/9fans/members> + delivery options
> <https://9fans.topicbox.com/groups/9fans/subscription> Permalink
> <https://9fans.topicbox.com/groups/9fans/Tc82cdeb7e597b9d2-M3acd2f3951c9034f283b33b1>
>
>

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tc82cdeb7e597b9d2-Meaff60439e36e8e26e963ce2
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 24390 bytes --]

Re: [9fans] NIX this evening

[Clout Tolstoy]

[-- Attachment #1: Type: text/plain, Size: 13290 bytes --]

Forgive the layman question but is NIX somewhat similar to cgroups in the
Linux kernel?

On Fri, Mar 7, 2025, 6:08 AM <tlaronde@kergis.com> wrote:

> On Thu, Mar 06, 2025 at 03:47:42PM -0800, ron minnich wrote:
> > thanks, Jacob.
> > I'm going to keep at it, and your rebase has now made it much easier to
> > keep up.
> >
> > In the usual manner of such things, I think now that we figured out that
> we
> > can make it work, it's time to toss a lot of those commits away, and get
> to
> > something a lot less messy. There's where others can help.
> >
>
> May I ask why you didn't keep the small nix set of files that you (I
> mean you Ron, and Paul) have finally selected?
>
> It seems to me that having, a la 9legacy (that has sys/src/9 and
> sys/src/9k), a sys/src/nix, that is having a git repo just nix, with a
> branch 9front (this flavor has just to be binded in 9front
> sys/src/nix) and, why not, a 9legacy (this flavor has just to binded
> in 9legacy sys/src/nix) would avoid the pain, for now, to have to
> update when 9front is moving and will have the supplementary benefit
> of showing what is Nix.
>
> IMHO, it seems it will be far more easier for people wanting to
> contribute to have just the Nix set of added or modified files in one
> directory and to let you and others joining focus on Nix related
> things without to have to bother merging or cherry picking
> "surroundings".
>
> Also a nix/nix for scaffolding scripts (building a namespace---in the
> case of a dedicated nix/ dir---, testing and so on).
>
> FWIW.
>
> T. Laronde
>
> > ron
> >
> > On Thu, Mar 6, 2025 at 3:38?PM Jacob Moody <moody@posixcafe.org> wrote:
> >
> > > On 3/6/25 15:07, ron minnich wrote:
> > > > Jacob re the rebase, thank you, it works in qemu and on my t420.
> > > >
> > > > I'm thinking to just set my 9front head to what you've done, push it
> to
> > > my fork, and proceed from there. Do you see any reason not to?
> > >
> > > Sure by all means.
> > >
> > > >
> > > > Where, ultimately, might we want NIX to land?
> > > >
> > > > I need to start turning the dial down on debug prints, to start.
> > >
> > > I think it depends on what the goals are here, I assume you're somewhat
> > > interested in having a conversation about getting
> > > nix in to 9front, so I'll start from there. Here's what I would
> suggest as
> > > the path forward for that and some followup questions.
> > >
> > > 1. You'll need to squash your changes in to a smaller organization of
> > > patches that can be reviewed, the current commit list is a bit messy
> > >         and does not follow our conventions for commit messages.
> > >
> > > 2. You'll need to make a case as to what the practical benefits are
> from
> > > having this capability, it seems like you've gotten somewhere with
> > >         the ftq benchmarks, which is great, but you'll need to put
> things
> > > in terms of practical benefit. What is a program on the system which
> > >         would benefit from having a core exclusive to itself? How can
> we
> > > prove that? Adding stuff to the Proc struct has a high impact and
> typically
> > >         should be accompanied by a decently useful addition.
> > >
> > > 3. Everything right now is specific to pc64, and I think if this is a
> > > general capability going forward, we're going to need this on the other
> > >         architectures that we support. At the very least arm64. I don't
> > > know if I would call this a requirement for getting nix merged but
> > >         it should be something that would be a close goal following an
> > > initial merge if not.
> > >
> > > 4. For now at least, I would suggest removing the debug prints. The
> > > question regarding on how to go forward with debug prints in general is
> > >         a good question, and something we can discuss but the
> discussion
> > > of nix and the discussion on debug prints are two separate discussions
> > >         (and ideally two separate patches). To this end I would
> perhaps be
> > > partial to having some sort of additional file (/dev/kdebug?) that
> > >         would serve some ring buffer that can be enabled with a write
> and
> > > would serve the results. (Think /net/log). This would be a bit more
> costly
> > >         compared to being able to #ifdef them out but I think in this
> case
> > > it may be worth it.
> > >
> > > Once you feel like you've got an organized set of diffs, the code
> cleaned
> > > up, and some sort of data to make an argument I would say post it over
> on
> > > the 9front list. Or perhaps pop your head in on irc or one of our jitsi
> > > calls to talk it out in real time.
> > >
> > > In general, and in particular with large impact changes like this,
> expect
> > > a lot of discussion on implementation, organization, and interface for
> these
> > > patches if you want to go forward with arguing for their inclusion in
> > > 9front. What I tend to do is regularly review the "big diff" against
> > > upstream
> > > and check that extra stuff hasn't snuck in.
> > >
> > > Stuff like:
> > >
> > >
> https://github.com/majiru/9front/compare/front...nix#diff-3530d7439c30d8e9125572d4c7eb0f42ca56b6adb8b069c7ce08c023c6067e48
> > >
> > >
> https://github.com/majiru/9front/compare/front...nix#diff-4fac6b341748f453f31ecd0d99acc52e6069bef0d85f51200d3a498f31acc9a0R20
> > >
> > >
> https://github.com/majiru/9front/compare/front...nix#diff-4fac6b341748f453f31ecd0d99acc52e6069bef0d85f51200d3a498f31acc9a0R43
> > >
> > > You've got some files which are lacking trailing newlines at the very
> end
> > > of the file as well that you'll want to clean up.
> > >
> > > The short of it is now that you've got things to a working state, I'd
> > > start cleaning stuff up, and start asking people to review
> > > these cleaned up version to get feedback on the implementation. If you
> > > agree that this is where you're at with this.
> > >
> > > >
> > > > on the original NIX, as we were in an HPC mindset, we made the only
> TC
> > > core 0, and all other cores ACs.
> > > >
> > > > I am wondering about a boot-time variable, such that, if not set,
> there
> > > are no ACs; and, if set, it means "all cores from this number up" are
> ACs.
> > >
> > > Some sort of plan9.ini setting, maybe just a list of core numbers that
> you
> > > want to be AC's? I'm thinking something that would allow you to set a
> > > specific
> > > list of cores. If for example your intel chip makes every odd numbered
> > > chip an E core, you may want to interleave them.
> > >
> > > >
> > > > Also ... re debugging ... do you have some way of controlling, on a
> > > fairly fine basis, when and how to print debug messages?
> > >
> > > I ended up addressing this in the above list.
> > >
> > > >
> > > > jmk had done something for 9k, which we also used on blue gene and
> then
> > > NIX, not sure when (2005? Charles, do you recall?) that worked like
> this:
> > > > in, e.g., pc64, you have a dbgflg section. You could define a single
> > > letter for a subsystem. So, e.g.,
> > > > dbgflg
> > > >     acore 'c'
> > > >     tcore 'c'
> > > >     ioapic 'I'
> > > >
> > > > There was a macro, DBG: DBG(...)
> > > > DBG acts like print if the dbgflg is set FOR THAT FILE.
> > > >
> > > > This all gets munged by awk and friends such that each .c can check
> > > dbgflg[_DBGC_] to see whether debug prints are enabled. That's all DBG
> is.
> > > >
> > > > You can make all debugging go away by defining a variable to be 0 and
> > > letting the linker do the elision (that's one variant of the
> definition of
> > > the macros, see
> > >
> https://github.com/rminnich/nix-os/blob/regen/sys/src/nix/k10/dat.h#L409 <
> https://github.com/rminnich/nix-os/blob/regen/sys/src/nix/k10/dat.h#L409>.
> > > Note a typical jmk comment: horrid :-)
> > > >
> > > > long story short, you could set debug flags in the command line or in
> > > plan9.ini, and DBG would be enabled or not in the various subsystems.
> It
> > > was a very easy way to turn debug on and off on a per-boot-time basis.
> > > >
> > > > It was nice, but it seems to have been lost in most plan 9 kernels.
> > > >
> > > > What do people do now in legacy/9front/whatever?
> > > >
> > > > Finally, for those trying to build NIX, no binds needed. git clone
> the
> > > repo of your choice, check out the branch, cd sys/src/9/pc64, and mk.
> > > >
> > > > Finally, ... coders welcome. The level of things to do is WAY less
> > > daunting now that we are sort of working, and part of the goal of
> bringing
> > > NIX back is to suck people in to working on the kernel.
> > > >
> > > > thanks
> > > >
> > > >
> > > > On Wed, Mar 5, 2025 at 1:57?PM <tlaronde@kergis.com <mailto:
> > > tlaronde@kergis.com>> wrote:
> > > >
> > > >     On Wed, Mar 05, 2025 at 09:16:57PM +0100, tlaronde@kergis.com
> > > <mailto:tlaronde@kergis.com> wrote:
> > > >     > On Wed, Mar 05, 2025 at 07:11:02PM +0100, tlaronde@kergis.com
> > > <mailto:tlaronde@kergis.com> wrote:
> > > >     > > I need to update the documentation about the building (one
> needs
> > > to
> > > >     > > bind above the 9front hier, but also to get
> plan9front/firmware,
> > > and
> > > >     > > to build and install brekky).
> > > >     > >
> > > >     > > But it also uses ftq.
> > > >     >
> > > >     > BTW, execac is missing also.
> > > >
> > > >     No: here ./sys/src/cmd/execac.c; needs simply to be compiled.
> > > >
> > > >     > >
> > > >     > > If I'm not mistaken, the git master has an unchanged mkfile
> > > relating
> > > >     > > to several flavors (ftq{15,31,63}) but is marked as broken.
> > > >     > >
> > > >     > > Do you compile it under APE?
> > > >     > >
> > > >     > > On Mon, Mar 03, 2025 at 07:44:47PM -0800, ron minnich wrote:
> > > >     > > > I am now able to run the HPC FTQ benchmark and get results,
> > > first time
> > > >     > > > since 2011.
> > > >     > > >
> > > >     > > > The results are very, very good on my T420. Next step, see
> how
> > > it goes on a
> > > >     > > > server class machine.
> > > >     > > >
> > > >     > > > If anyone wants to help out, the rebase would be most
> welcome,
> > > as would
> > > >     > > > testing of your choice.
> > > >     > > >
> > > >     > > > Taking a trap on an AC still does not work. I get around
> that
> > > by making
> > > >     > > > sure traps won't happen but ... would be nice to fix it.
> > > >     > > >
> > > >     > > > In NIX, we had a new rfork type which would let a process
> flip
> > > itself onto
> > > >     > > > an AC; it would be useful to bring that over.
> > > >     > > >
> > > >     > > > Lots to do, whoever wants to help, we're open for business.
> > > >     > >
> > > >     > > --
> > > >     > > Thierry Laronde <tlaronde +AT+ kergis +dot+ com>
> > > >     > >              http://www.kergis.com/ <http://www.kergis.com/>
> > > >     > >             http://kertex.kergis.com/ <
> http://kertex.kergis.com/
> > > >     > > Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95
> 6006
> > > F40C
> > > >     >
> > > >     > --
> > > >     >         Thierry Laronde <tlaronde +AT+ kergis +dot+ com>
> > > >     >                      http://www.kergis.com/ <
> > > http://www.kergis.com/>
> > > >     >                     http://kertex.kergis.com/ <
> > > http://kertex.kergis.com/>
> > > >     > Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006
> > > F40C
> > > >
> > > >     --
> > > >             Thierry Laronde <tlaronde +AT+ kergis +dot+ com>
> > > >                          http://www.kergis.com/ <
> http://www.kergis.com/>
> > > >                         http://kertex.kergis.com/ <
> > > http://kertex.kergis.com/>
> > > >     Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006
> F40C
> > > >
> > > >     ------------------------------------------
> > > >     9fans: 9fans
> > > >     Permalink:
> https://9fans.topicbox.com/groups/9fans/Tc82cdeb7e597b9d2-M39192ec6eef3979dd0ea7579
> > > <
> > >
> https://9fans.topicbox.com/groups/9fans/Tc82cdeb7e597b9d2-M39192ec6eef3979dd0ea7579
> > > >
> > > >     Delivery options:
> > > https://9fans.topicbox.com/groups/9fans/subscription <
> > > https://9fans.topicbox.com/groups/9fans/subscription>
> > > >
> > > > *9fans <https://9fans.topicbox.com/latest>* / 9fans / see
> discussions <
> > > https://9fans.topicbox.com/groups/9fans> + participants <
> > > https://9fans.topicbox.com/groups/9fans/members> + delivery options <
> > > https://9fans.topicbox.com/groups/9fans/subscription> Permalink <
> > >
> https://9fans.topicbox.com/groups/9fans/Tc82cdeb7e597b9d2-M90f81cabe64c4d4bcdcfd5c7
> 
> --
> 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
Permalink: https://9fans.topicbox.com/groups/9fans/Tc82cdeb7e597b9d2-M3acd2f3951c9034f283b33b1
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 22853 bytes --]

Re: [9fans] NIX this evening

[ron minnich]

[-- Attachment #1: Type: text/plain, Size: 14125 bytes --]

The bind approach looked ok for a while. But the problem is the NIX changes
are pretty intrusive. Here are the new files:
sys/src/9/pc64/acore.c
sys/src/9/pc64/nix.s
sys/src/9/pc64/tcore.c
sys/src/cmd/execac.c

there are about 30 changed files, but only 4 new ones. Now, some change we
can get along without (bootfs.proto) , some changes we can not
(syscallfmt.c). We need to track the files we change, e.g. portdat.h, as
they change upstream, and git is pretty good at that kind of thing.

Past a point, the bind approach gets really clumsy. Maintaining a branch is
very easy in git, and for unchanged files, the blobs will be the same.
There's not a big storage penalty. Well, in practice, it's almost zero.
For my work, I will continue with a branch I can rebase over time. But if
you'd prefer a different approach, I certainly won't get in your way :-)

I think the branch approach wins here.

ron

On Fri, Mar 7, 2025 at 6:08 AM <tlaronde@kergis.com> wrote:

> On Thu, Mar 06, 2025 at 03:47:42PM -0800, ron minnich wrote:
> > thanks, Jacob.
> > I'm going to keep at it, and your rebase has now made it much easier to
> > keep up.
> >
> > In the usual manner of such things, I think now that we figured out that
> we
> > can make it work, it's time to toss a lot of those commits away, and get
> to
> > something a lot less messy. There's where others can help.
> >
>
> May I ask why you didn't keep the small nix set of files that you (I
> mean you Ron, and Paul) have finally selected?
>
> It seems to me that having, a la 9legacy (that has sys/src/9 and
> sys/src/9k), a sys/src/nix, that is having a git repo just nix, with a
> branch 9front (this flavor has just to be binded in 9front
> sys/src/nix) and, why not, a 9legacy (this flavor has just to binded
> in 9legacy sys/src/nix) would avoid the pain, for now, to have to
> update when 9front is moving and will have the supplementary benefit
> of showing what is Nix.
>
> IMHO, it seems it will be far more easier for people wanting to
> contribute to have just the Nix set of added or modified files in one
> directory and to let you and others joining focus on Nix related
> things without to have to bother merging or cherry picking
> "surroundings".
>
> Also a nix/nix for scaffolding scripts (building a namespace---in the
> case of a dedicated nix/ dir---, testing and so on).
>
> FWIW.
>
> T. Laronde
>
> > ron
> >
> > On Thu, Mar 6, 2025 at 3:38?PM Jacob Moody <moody@posixcafe.org> wrote:
> >
> > > On 3/6/25 15:07, ron minnich wrote:
> > > > Jacob re the rebase, thank you, it works in qemu and on my t420.
> > > >
> > > > I'm thinking to just set my 9front head to what you've done, push it
> to
> > > my fork, and proceed from there. Do you see any reason not to?
> > >
> > > Sure by all means.
> > >
> > > >
> > > > Where, ultimately, might we want NIX to land?
> > > >
> > > > I need to start turning the dial down on debug prints, to start.
> > >
> > > I think it depends on what the goals are here, I assume you're somewhat
> > > interested in having a conversation about getting
> > > nix in to 9front, so I'll start from there. Here's what I would
> suggest as
> > > the path forward for that and some followup questions.
> > >
> > > 1. You'll need to squash your changes in to a smaller organization of
> > > patches that can be reviewed, the current commit list is a bit messy
> > >         and does not follow our conventions for commit messages.
> > >
> > > 2. You'll need to make a case as to what the practical benefits are
> from
> > > having this capability, it seems like you've gotten somewhere with
> > >         the ftq benchmarks, which is great, but you'll need to put
> things
> > > in terms of practical benefit. What is a program on the system which
> > >         would benefit from having a core exclusive to itself? How can
> we
> > > prove that? Adding stuff to the Proc struct has a high impact and
> typically
> > >         should be accompanied by a decently useful addition.
> > >
> > > 3. Everything right now is specific to pc64, and I think if this is a
> > > general capability going forward, we're going to need this on the other
> > >         architectures that we support. At the very least arm64. I don't
> > > know if I would call this a requirement for getting nix merged but
> > >         it should be something that would be a close goal following an
> > > initial merge if not.
> > >
> > > 4. For now at least, I would suggest removing the debug prints. The
> > > question regarding on how to go forward with debug prints in general is
> > >         a good question, and something we can discuss but the
> discussion
> > > of nix and the discussion on debug prints are two separate discussions
> > >         (and ideally two separate patches). To this end I would
> perhaps be
> > > partial to having some sort of additional file (/dev/kdebug?) that
> > >         would serve some ring buffer that can be enabled with a write
> and
> > > would serve the results. (Think /net/log). This would be a bit more
> costly
> > >         compared to being able to #ifdef them out but I think in this
> case
> > > it may be worth it.
> > >
> > > Once you feel like you've got an organized set of diffs, the code
> cleaned
> > > up, and some sort of data to make an argument I would say post it over
> on
> > > the 9front list. Or perhaps pop your head in on irc or one of our jitsi
> > > calls to talk it out in real time.
> > >
> > > In general, and in particular with large impact changes like this,
> expect
> > > a lot of discussion on implementation, organization, and interface for
> these
> > > patches if you want to go forward with arguing for their inclusion in
> > > 9front. What I tend to do is regularly review the "big diff" against
> > > upstream
> > > and check that extra stuff hasn't snuck in.
> > >
> > > Stuff like:
> > >
> > >
> https://github.com/majiru/9front/compare/front...nix#diff-3530d7439c30d8e9125572d4c7eb0f42ca56b6adb8b069c7ce08c023c6067e48
> > >
> > >
> https://github.com/majiru/9front/compare/front...nix#diff-4fac6b341748f453f31ecd0d99acc52e6069bef0d85f51200d3a498f31acc9a0R20
> > >
> > >
> https://github.com/majiru/9front/compare/front...nix#diff-4fac6b341748f453f31ecd0d99acc52e6069bef0d85f51200d3a498f31acc9a0R43
> > >
> > > You've got some files which are lacking trailing newlines at the very
> end
> > > of the file as well that you'll want to clean up.
> > >
> > > The short of it is now that you've got things to a working state, I'd
> > > start cleaning stuff up, and start asking people to review
> > > these cleaned up version to get feedback on the implementation. If you
> > > agree that this is where you're at with this.
> > >
> > > >
> > > > on the original NIX, as we were in an HPC mindset, we made the only
> TC
> > > core 0, and all other cores ACs.
> > > >
> > > > I am wondering about a boot-time variable, such that, if not set,
> there
> > > are no ACs; and, if set, it means "all cores from this number up" are
> ACs.
> > >
> > > Some sort of plan9.ini setting, maybe just a list of core numbers that
> you
> > > want to be AC's? I'm thinking something that would allow you to set a
> > > specific
> > > list of cores. If for example your intel chip makes every odd numbered
> > > chip an E core, you may want to interleave them.
> > >
> > > >
> > > > Also ... re debugging ... do you have some way of controlling, on a
> > > fairly fine basis, when and how to print debug messages?
> > >
> > > I ended up addressing this in the above list.
> > >
> > > >
> > > > jmk had done something for 9k, which we also used on blue gene and
> then
> > > NIX, not sure when (2005? Charles, do you recall?) that worked like
> this:
> > > > in, e.g., pc64, you have a dbgflg section. You could define a single
> > > letter for a subsystem. So, e.g.,
> > > > dbgflg
> > > >     acore 'c'
> > > >     tcore 'c'
> > > >     ioapic 'I'
> > > >
> > > > There was a macro, DBG: DBG(...)
> > > > DBG acts like print if the dbgflg is set FOR THAT FILE.
> > > >
> > > > This all gets munged by awk and friends such that each .c can check
> > > dbgflg[_DBGC_] to see whether debug prints are enabled. That's all DBG
> is.
> > > >
> > > > You can make all debugging go away by defining a variable to be 0 and
> > > letting the linker do the elision (that's one variant of the
> definition of
> > > the macros, see
> > >
> https://github.com/rminnich/nix-os/blob/regen/sys/src/nix/k10/dat.h#L409 <
> https://github.com/rminnich/nix-os/blob/regen/sys/src/nix/k10/dat.h#L409>.
> > > Note a typical jmk comment: horrid :-)
> > > >
> > > > long story short, you could set debug flags in the command line or in
> > > plan9.ini, and DBG would be enabled or not in the various subsystems.
> It
> > > was a very easy way to turn debug on and off on a per-boot-time basis.
> > > >
> > > > It was nice, but it seems to have been lost in most plan 9 kernels.
> > > >
> > > > What do people do now in legacy/9front/whatever?
> > > >
> > > > Finally, for those trying to build NIX, no binds needed. git clone
> the
> > > repo of your choice, check out the branch, cd sys/src/9/pc64, and mk.
> > > >
> > > > Finally, ... coders welcome. The level of things to do is WAY less
> > > daunting now that we are sort of working, and part of the goal of
> bringing
> > > NIX back is to suck people in to working on the kernel.
> > > >
> > > > thanks
> > > >
> > > >
> > > > On Wed, Mar 5, 2025 at 1:57?PM <tlaronde@kergis.com <mailto:
> > > tlaronde@kergis.com>> wrote:
> > > >
> > > >     On Wed, Mar 05, 2025 at 09:16:57PM +0100, tlaronde@kergis.com
> > > <mailto:tlaronde@kergis.com> wrote:
> > > >     > On Wed, Mar 05, 2025 at 07:11:02PM +0100, tlaronde@kergis.com
> > > <mailto:tlaronde@kergis.com> wrote:
> > > >     > > I need to update the documentation about the building (one
> needs
> > > to
> > > >     > > bind above the 9front hier, but also to get
> plan9front/firmware,
> > > and
> > > >     > > to build and install brekky).
> > > >     > >
> > > >     > > But it also uses ftq.
> > > >     >
> > > >     > BTW, execac is missing also.
> > > >
> > > >     No: here ./sys/src/cmd/execac.c; needs simply to be compiled.
> > > >
> > > >     > >
> > > >     > > If I'm not mistaken, the git master has an unchanged mkfile
> > > relating
> > > >     > > to several flavors (ftq{15,31,63}) but is marked as broken.
> > > >     > >
> > > >     > > Do you compile it under APE?
> > > >     > >
> > > >     > > On Mon, Mar 03, 2025 at 07:44:47PM -0800, ron minnich wrote:
> > > >     > > > I am now able to run the HPC FTQ benchmark and get results,
> > > first time
> > > >     > > > since 2011.
> > > >     > > >
> > > >     > > > The results are very, very good on my T420. Next step, see
> how
> > > it goes on a
> > > >     > > > server class machine.
> > > >     > > >
> > > >     > > > If anyone wants to help out, the rebase would be most
> welcome,
> > > as would
> > > >     > > > testing of your choice.
> > > >     > > >
> > > >     > > > Taking a trap on an AC still does not work. I get around
> that
> > > by making
> > > >     > > > sure traps won't happen but ... would be nice to fix it.
> > > >     > > >
> > > >     > > > In NIX, we had a new rfork type which would let a process
> flip
> > > itself onto
> > > >     > > > an AC; it would be useful to bring that over.
> > > >     > > >
> > > >     > > > Lots to do, whoever wants to help, we're open for business.
> > > >     > >
> > > >     > > --
> > > >     > > Thierry Laronde <tlaronde +AT+ kergis +dot+ com>
> > > >     > >              http://www.kergis.com/ <http://www.kergis.com/>
> > > >     > >             http://kertex.kergis.com/ <
> http://kertex.kergis.com/
> > > >     > > Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95
> 6006
> > > F40C
> > > >     >
> > > >     > --
> > > >     >         Thierry Laronde <tlaronde +AT+ kergis +dot+ com>
> > > >     >                      http://www.kergis.com/ <
> > > http://www.kergis.com/>
> > > >     >                     http://kertex.kergis.com/ <
> > > http://kertex.kergis.com/>
> > > >     > Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006
> > > F40C
> > > >
> > > >     --
> > > >             Thierry Laronde <tlaronde +AT+ kergis +dot+ com>
> > > >                          http://www.kergis.com/ <
> http://www.kergis.com/>
> > > >                         http://kertex.kergis.com/ <
> > > http://kertex.kergis.com/>
> > > >     Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006
> F40C
> > > >
> > > >     ------------------------------------------
> > > >     9fans: 9fans
> > > >     Permalink:
> https://9fans.topicbox.com/groups/9fans/Tc82cdeb7e597b9d2-M39192ec6eef3979dd0ea7579
> > > <
> > >
> https://9fans.topicbox.com/groups/9fans/Tc82cdeb7e597b9d2-M39192ec6eef3979dd0ea7579
> > > >
> > > >     Delivery options:
> > > https://9fans.topicbox.com/groups/9fans/subscription <
> > > https://9fans.topicbox.com/groups/9fans/subscription>
> > > >
> > > > *9fans <https://9fans.topicbox.com/latest>* / 9fans / see
> discussions <
> > > https://9fans.topicbox.com/groups/9fans> + participants <
> > > https://9fans.topicbox.com/groups/9fans/members> + delivery options <
> > > https://9fans.topicbox.com/groups/9fans/subscription> Permalink <
> > >
> https://9fans.topicbox.com/groups/9fans/Tc82cdeb7e597b9d2-M90f81cabe64c4d4bcdcfd5c7
> 
> --
> 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
Permalink: https://9fans.topicbox.com/groups/9fans/Tc82cdeb7e597b9d2-M6c8daee35ba694e5ed12cb21
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 23455 bytes --]

Re: [9fans] NIX this evening

[Jacob Moody]

On 3/7/25 06:10, tlaronde@kergis.com wrote:
> On Thu, Mar 06, 2025 at 03:47:42PM -0800, ron minnich wrote:
>> thanks, Jacob.
>> I'm going to keep at it, and your rebase has now made it much easier to
>> keep up.
>>
>> In the usual manner of such things, I think now that we figured out that we
>> can make it work, it's time to toss a lot of those commits away, and get to
>> something a lot less messy. There's where others can help.
>>
> 
> May I ask why you didn't keep the small nix set of files that you (I
> mean you Ron, and Paul) have finally selected?
> 
> It seems to me that having, a la 9legacy (that has sys/src/9 and
> sys/src/9k), a sys/src/nix, that is having a git repo just nix, with a
> branch 9front (this flavor has just to be binded in 9front
> sys/src/nix) and, why not, a 9legacy (this flavor has just to binded
> in 9legacy sys/src/nix) would avoid the pain, for now, to have to
> update when 9front is moving and will have the supplementary benefit
> of showing what is Nix.

The main issue is that nix is not self contained, presumably the nix kernel
wants access to 9front's drivers, multiboot, nvme support etc.
The process of rebasing via cherry pick (I had to do that specifically because
of how the git tree was kind of interwoven with 9front commits,
if it was just the 9front tree with only nix commits on tab it would be been almost instant)
is really not that involved, I did it in maybe 10 minutes.

If you do want to maintain nix out of the main 9front tree you'll need to reconcile this
dependency on other parts of the kernel code somehow. You can either do as is being done
already, which is have a series of commits that are on top of 9front that you rebase
periodically. Or you could vendor everything that nix uses in a way that would allow
it to work independently of the state of your local 9front system. Even in the vendor
case you'll still have to reconcile changes upstream as bugs are found and drivers improved.
At least in the "rebease method" it makes things much more explicit, in my opinion.

Also to be frank I would find it highly unlikely that a single repository would work for
both 9legacy and 9front, 9front has made lots of improvements to the kernels over the years and
at this point you'd either have to pick one as your base branch (or source of your vendor) or
the other. When I looked at importing Richard Miller and Geoff's riscv(64) work my conclusion was
that things had drifted enough that it would be better to start from scratch.

> 
> IMHO, it seems it will be far more easier for people wanting to
> contribute to have just the Nix set of added or modified files in one
> directory and to let you and others joining focus on Nix related
> things without to have to bother merging or cherry picking
> "surroundings".

Given all of what I've said I think what Ron has been doing right now,
which is just maintaining a series of commits on top of 9front is the path of least resistance.
This is the same way I tracked my own development when I was working on power64 and riscv support.
In regards to the "bother" of merging, I really don't think its much of a bother.
It is a process sure, but one that has a very positive impact on the code and design.
Pretty much every large change I've done has been helped tremendously from the input of other
community members. Even if nix remains out of tree, the feedback could help improve the quality
of nix in isolation.

> 
> Also a nix/nix for scaffolding scripts (building a namespace---in the
> case of a dedicated nix/ dir---, testing and so on).
> 

Sure, that would be a help in maintaining nix in isolation but it won't
remove all of the dependencies that nix has on existing code.



Thanks,
Jacob Moody


------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tc82cdeb7e597b9d2-M4d2857713c96be19b0db1050
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] NIX this evening

[tlaronde]

On Thu, Mar 06, 2025 at 03:47:42PM -0800, ron minnich wrote:
> thanks, Jacob.
> I'm going to keep at it, and your rebase has now made it much easier to
> keep up.
> 
> In the usual manner of such things, I think now that we figured out that we
> can make it work, it's time to toss a lot of those commits away, and get to
> something a lot less messy. There's where others can help.
> 

May I ask why you didn't keep the small nix set of files that you (I
mean you Ron, and Paul) have finally selected?

It seems to me that having, a la 9legacy (that has sys/src/9 and
sys/src/9k), a sys/src/nix, that is having a git repo just nix, with a
branch 9front (this flavor has just to be binded in 9front
sys/src/nix) and, why not, a 9legacy (this flavor has just to binded
in 9legacy sys/src/nix) would avoid the pain, for now, to have to
update when 9front is moving and will have the supplementary benefit
of showing what is Nix.

IMHO, it seems it will be far more easier for people wanting to
contribute to have just the Nix set of added or modified files in one
directory and to let you and others joining focus on Nix related
things without to have to bother merging or cherry picking
"surroundings".

Also a nix/nix for scaffolding scripts (building a namespace---in the
case of a dedicated nix/ dir---, testing and so on).

FWIW.

T. Laronde

> ron
> 
> On Thu, Mar 6, 2025 at 3:38?PM Jacob Moody <moody@posixcafe.org> wrote:
> 
> > On 3/6/25 15:07, ron minnich wrote:
> > > Jacob re the rebase, thank you, it works in qemu and on my t420.
> > >
> > > I'm thinking to just set my 9front head to what you've done, push it to
> > my fork, and proceed from there. Do you see any reason not to?
> >
> > Sure by all means.
> >
> > >
> > > Where, ultimately, might we want NIX to land?
> > >
> > > I need to start turning the dial down on debug prints, to start.
> >
> > I think it depends on what the goals are here, I assume you're somewhat
> > interested in having a conversation about getting
> > nix in to 9front, so I'll start from there. Here's what I would suggest as
> > the path forward for that and some followup questions.
> >
> > 1. You'll need to squash your changes in to a smaller organization of
> > patches that can be reviewed, the current commit list is a bit messy
> >         and does not follow our conventions for commit messages.
> >
> > 2. You'll need to make a case as to what the practical benefits are from
> > having this capability, it seems like you've gotten somewhere with
> >         the ftq benchmarks, which is great, but you'll need to put things
> > in terms of practical benefit. What is a program on the system which
> >         would benefit from having a core exclusive to itself? How can we
> > prove that? Adding stuff to the Proc struct has a high impact and typically
> >         should be accompanied by a decently useful addition.
> >
> > 3. Everything right now is specific to pc64, and I think if this is a
> > general capability going forward, we're going to need this on the other
> >         architectures that we support. At the very least arm64. I don't
> > know if I would call this a requirement for getting nix merged but
> >         it should be something that would be a close goal following an
> > initial merge if not.
> >
> > 4. For now at least, I would suggest removing the debug prints. The
> > question regarding on how to go forward with debug prints in general is
> >         a good question, and something we can discuss but the discussion
> > of nix and the discussion on debug prints are two separate discussions
> >         (and ideally two separate patches). To this end I would perhaps be
> > partial to having some sort of additional file (/dev/kdebug?) that
> >         would serve some ring buffer that can be enabled with a write and
> > would serve the results. (Think /net/log). This would be a bit more costly
> >         compared to being able to #ifdef them out but I think in this case
> > it may be worth it.
> >
> > Once you feel like you've got an organized set of diffs, the code cleaned
> > up, and some sort of data to make an argument I would say post it over on
> > the 9front list. Or perhaps pop your head in on irc or one of our jitsi
> > calls to talk it out in real time.
> >
> > In general, and in particular with large impact changes like this, expect
> > a lot of discussion on implementation, organization, and interface for these
> > patches if you want to go forward with arguing for their inclusion in
> > 9front. What I tend to do is regularly review the "big diff" against
> > upstream
> > and check that extra stuff hasn't snuck in.
> >
> > Stuff like:
> >
> > https://github.com/majiru/9front/compare/front...nix#diff-3530d7439c30d8e9125572d4c7eb0f42ca56b6adb8b069c7ce08c023c6067e48
> >
> > https://github.com/majiru/9front/compare/front...nix#diff-4fac6b341748f453f31ecd0d99acc52e6069bef0d85f51200d3a498f31acc9a0R20
> >
> > https://github.com/majiru/9front/compare/front...nix#diff-4fac6b341748f453f31ecd0d99acc52e6069bef0d85f51200d3a498f31acc9a0R43
> >
> > You've got some files which are lacking trailing newlines at the very end
> > of the file as well that you'll want to clean up.
> >
> > The short of it is now that you've got things to a working state, I'd
> > start cleaning stuff up, and start asking people to review
> > these cleaned up version to get feedback on the implementation. If you
> > agree that this is where you're at with this.
> >
> > >
> > > on the original NIX, as we were in an HPC mindset, we made the only TC
> > core 0, and all other cores ACs.
> > >
> > > I am wondering about a boot-time variable, such that, if not set, there
> > are no ACs; and, if set, it means "all cores from this number up" are ACs.
> >
> > Some sort of plan9.ini setting, maybe just a list of core numbers that you
> > want to be AC's? I'm thinking something that would allow you to set a
> > specific
> > list of cores. If for example your intel chip makes every odd numbered
> > chip an E core, you may want to interleave them.
> >
> > >
> > > Also ... re debugging ... do you have some way of controlling, on a
> > fairly fine basis, when and how to print debug messages?
> >
> > I ended up addressing this in the above list.
> >
> > >
> > > jmk had done something for 9k, which we also used on blue gene and then
> > NIX, not sure when (2005? Charles, do you recall?) that worked like this:
> > > in, e.g., pc64, you have a dbgflg section. You could define a single
> > letter for a subsystem. So, e.g.,
> > > dbgflg
> > >     acore 'c'
> > >     tcore 'c'
> > >     ioapic 'I'
> > >
> > > There was a macro, DBG: DBG(...)
> > > DBG acts like print if the dbgflg is set FOR THAT FILE.
> > >
> > > This all gets munged by awk and friends such that each .c can check
> > dbgflg[_DBGC_] to see whether debug prints are enabled. That's all DBG is.
> > >
> > > You can make all debugging go away by defining a variable to be 0 and
> > letting the linker do the elision (that's one variant of the definition of
> > the macros, see
> > https://github.com/rminnich/nix-os/blob/regen/sys/src/nix/k10/dat.h#L409 <
> > https://github.com/rminnich/nix-os/blob/regen/sys/src/nix/k10/dat.h#L409>.
> > Note a typical jmk comment: horrid :-)
> > >
> > > long story short, you could set debug flags in the command line or in
> > plan9.ini, and DBG would be enabled or not in the various subsystems. It
> > was a very easy way to turn debug on and off on a per-boot-time basis.
> > >
> > > It was nice, but it seems to have been lost in most plan 9 kernels.
> > >
> > > What do people do now in legacy/9front/whatever?
> > >
> > > Finally, for those trying to build NIX, no binds needed. git clone the
> > repo of your choice, check out the branch, cd sys/src/9/pc64, and mk.
> > >
> > > Finally, ... coders welcome. The level of things to do is WAY less
> > daunting now that we are sort of working, and part of the goal of bringing
> > NIX back is to suck people in to working on the kernel.
> > >
> > > thanks
> > >
> > >
> > > On Wed, Mar 5, 2025 at 1:57?PM <tlaronde@kergis.com <mailto:
> > tlaronde@kergis.com>> wrote:
> > >
> > >     On Wed, Mar 05, 2025 at 09:16:57PM +0100, tlaronde@kergis.com
> > <mailto:tlaronde@kergis.com> wrote:
> > >     > On Wed, Mar 05, 2025 at 07:11:02PM +0100, tlaronde@kergis.com
> > <mailto:tlaronde@kergis.com> wrote:
> > >     > > I need to update the documentation about the building (one needs
> > to
> > >     > > bind above the 9front hier, but also to get plan9front/firmware,
> > and
> > >     > > to build and install brekky).
> > >     > >
> > >     > > But it also uses ftq.
> > >     >
> > >     > BTW, execac is missing also.
> > >
> > >     No: here ./sys/src/cmd/execac.c; needs simply to be compiled.
> > >
> > >     > >
> > >     > > If I'm not mistaken, the git master has an unchanged mkfile
> > relating
> > >     > > to several flavors (ftq{15,31,63}) but is marked as broken.
> > >     > >
> > >     > > Do you compile it under APE?
> > >     > >
> > >     > > On Mon, Mar 03, 2025 at 07:44:47PM -0800, ron minnich wrote:
> > >     > > > I am now able to run the HPC FTQ benchmark and get results,
> > first time
> > >     > > > since 2011.
> > >     > > >
> > >     > > > The results are very, very good on my T420. Next step, see how
> > it goes on a
> > >     > > > server class machine.
> > >     > > >
> > >     > > > If anyone wants to help out, the rebase would be most welcome,
> > as would
> > >     > > > testing of your choice.
> > >     > > >
> > >     > > > Taking a trap on an AC still does not work. I get around that
> > by making
> > >     > > > sure traps won't happen but ... would be nice to fix it.
> > >     > > >
> > >     > > > In NIX, we had a new rfork type which would let a process flip
> > itself onto
> > >     > > > an AC; it would be useful to bring that over.
> > >     > > >
> > >     > > > Lots to do, whoever wants to help, we're open for business.
> > >     > >
> > >     > > --
> > >     > > Thierry Laronde <tlaronde +AT+ kergis +dot+ com>
> > >     > >              http://www.kergis.com/ <http://www.kergis.com/>
> > >     > >             http://kertex.kergis.com/ <http://kertex.kergis.com/
> > >     > > Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006
> > F40C
> > >     >
> > >     > --
> > >     >         Thierry Laronde <tlaronde +AT+ kergis +dot+ com>
> > >     >                      http://www.kergis.com/ <
> > http://www.kergis.com/>
> > >     >                     http://kertex.kergis.com/ <
> > http://kertex.kergis.com/>
> > >     > Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006
> > F40C
> > >
> > >     --
> > >             Thierry Laronde <tlaronde +AT+ kergis +dot+ com>
> > >                          http://www.kergis.com/ <http://www.kergis.com/>
> > >                         http://kertex.kergis.com/ <
> > http://kertex.kergis.com/>
> > >     Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C
> > >
> > >     ------------------------------------------
> > >     9fans: 9fans
> > >     Permalink:
> > https://9fans.topicbox.com/groups/9fans/Tc82cdeb7e597b9d2-M39192ec6eef3979dd0ea7579
> > <
> > https://9fans.topicbox.com/groups/9fans/Tc82cdeb7e597b9d2-M39192ec6eef3979dd0ea7579
> > >
> > >     Delivery options:
> > https://9fans.topicbox.com/groups/9fans/subscription <
> > https://9fans.topicbox.com/groups/9fans/subscription>
> > >
> > > *9fans <https://9fans.topicbox.com/latest>* / 9fans / see discussions <
> > https://9fans.topicbox.com/groups/9fans> + participants <
> > https://9fans.topicbox.com/groups/9fans/members> + delivery options <
> > https://9fans.topicbox.com/groups/9fans/subscription> Permalink <
> > https://9fans.topicbox.com/groups/9fans/Tc82cdeb7e597b9d2-M90f81cabe64c4d4bcdcfd5c7

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

Re: [9fans] NIX this evening

[ron minnich]

[-- Attachment #1: Type: text/plain, Size: 10761 bytes --]

thanks, Jacob.
I'm going to keep at it, and your rebase has now made it much easier to
keep up.

In the usual manner of such things, I think now that we figured out that we
can make it work, it's time to toss a lot of those commits away, and get to
something a lot less messy. There's where others can help.

ron

On Thu, Mar 6, 2025 at 3:38 PM Jacob Moody <moody@posixcafe.org> wrote:

> On 3/6/25 15:07, ron minnich wrote:
> > Jacob re the rebase, thank you, it works in qemu and on my t420.
> >
> > I'm thinking to just set my 9front head to what you've done, push it to
> my fork, and proceed from there. Do you see any reason not to?
>
> Sure by all means.
>
> >
> > Where, ultimately, might we want NIX to land?
> >
> > I need to start turning the dial down on debug prints, to start.
>
> I think it depends on what the goals are here, I assume you're somewhat
> interested in having a conversation about getting
> nix in to 9front, so I'll start from there. Here's what I would suggest as
> the path forward for that and some followup questions.
>
> 1. You'll need to squash your changes in to a smaller organization of
> patches that can be reviewed, the current commit list is a bit messy
>         and does not follow our conventions for commit messages.
>
> 2. You'll need to make a case as to what the practical benefits are from
> having this capability, it seems like you've gotten somewhere with
>         the ftq benchmarks, which is great, but you'll need to put things
> in terms of practical benefit. What is a program on the system which
>         would benefit from having a core exclusive to itself? How can we
> prove that? Adding stuff to the Proc struct has a high impact and typically
>         should be accompanied by a decently useful addition.
>
> 3. Everything right now is specific to pc64, and I think if this is a
> general capability going forward, we're going to need this on the other
>         architectures that we support. At the very least arm64. I don't
> know if I would call this a requirement for getting nix merged but
>         it should be something that would be a close goal following an
> initial merge if not.
>
> 4. For now at least, I would suggest removing the debug prints. The
> question regarding on how to go forward with debug prints in general is
>         a good question, and something we can discuss but the discussion
> of nix and the discussion on debug prints are two separate discussions
>         (and ideally two separate patches). To this end I would perhaps be
> partial to having some sort of additional file (/dev/kdebug?) that
>         would serve some ring buffer that can be enabled with a write and
> would serve the results. (Think /net/log). This would be a bit more costly
>         compared to being able to #ifdef them out but I think in this case
> it may be worth it.
>
> Once you feel like you've got an organized set of diffs, the code cleaned
> up, and some sort of data to make an argument I would say post it over on
> the 9front list. Or perhaps pop your head in on irc or one of our jitsi
> calls to talk it out in real time.
>
> In general, and in particular with large impact changes like this, expect
> a lot of discussion on implementation, organization, and interface for these
> patches if you want to go forward with arguing for their inclusion in
> 9front. What I tend to do is regularly review the "big diff" against
> upstream
> and check that extra stuff hasn't snuck in.
>
> Stuff like:
>
> https://github.com/majiru/9front/compare/front...nix#diff-3530d7439c30d8e9125572d4c7eb0f42ca56b6adb8b069c7ce08c023c6067e48
>
> https://github.com/majiru/9front/compare/front...nix#diff-4fac6b341748f453f31ecd0d99acc52e6069bef0d85f51200d3a498f31acc9a0R20
>
> https://github.com/majiru/9front/compare/front...nix#diff-4fac6b341748f453f31ecd0d99acc52e6069bef0d85f51200d3a498f31acc9a0R43
>
> You've got some files which are lacking trailing newlines at the very end
> of the file as well that you'll want to clean up.
>
> The short of it is now that you've got things to a working state, I'd
> start cleaning stuff up, and start asking people to review
> these cleaned up version to get feedback on the implementation. If you
> agree that this is where you're at with this.
>
> >
> > on the original NIX, as we were in an HPC mindset, we made the only TC
> core 0, and all other cores ACs.
> >
> > I am wondering about a boot-time variable, such that, if not set, there
> are no ACs; and, if set, it means "all cores from this number up" are ACs.
>
> Some sort of plan9.ini setting, maybe just a list of core numbers that you
> want to be AC's? I'm thinking something that would allow you to set a
> specific
> list of cores. If for example your intel chip makes every odd numbered
> chip an E core, you may want to interleave them.
>
> >
> > Also ... re debugging ... do you have some way of controlling, on a
> fairly fine basis, when and how to print debug messages?
>
> I ended up addressing this in the above list.
>
> >
> > jmk had done something for 9k, which we also used on blue gene and then
> NIX, not sure when (2005? Charles, do you recall?) that worked like this:
> > in, e.g., pc64, you have a dbgflg section. You could define a single
> letter for a subsystem. So, e.g.,
> > dbgflg
> >     acore 'c'
> >     tcore 'c'
> >     ioapic 'I'
> >
> > There was a macro, DBG: DBG(...)
> > DBG acts like print if the dbgflg is set FOR THAT FILE.
> >
> > This all gets munged by awk and friends such that each .c can check
> dbgflg[_DBGC_] to see whether debug prints are enabled. That's all DBG is.
> >
> > You can make all debugging go away by defining a variable to be 0 and
> letting the linker do the elision (that's one variant of the definition of
> the macros, see
> https://github.com/rminnich/nix-os/blob/regen/sys/src/nix/k10/dat.h#L409 <
> https://github.com/rminnich/nix-os/blob/regen/sys/src/nix/k10/dat.h#L409>.
> Note a typical jmk comment: horrid :-)
> >
> > long story short, you could set debug flags in the command line or in
> plan9.ini, and DBG would be enabled or not in the various subsystems. It
> was a very easy way to turn debug on and off on a per-boot-time basis.
> >
> > It was nice, but it seems to have been lost in most plan 9 kernels.
> >
> > What do people do now in legacy/9front/whatever?
> >
> > Finally, for those trying to build NIX, no binds needed. git clone the
> repo of your choice, check out the branch, cd sys/src/9/pc64, and mk.
> >
> > Finally, ... coders welcome. The level of things to do is WAY less
> daunting now that we are sort of working, and part of the goal of bringing
> NIX back is to suck people in to working on the kernel.
> >
> > thanks
> >
> >
> > On Wed, Mar 5, 2025 at 1:57 PM <tlaronde@kergis.com <mailto:
> tlaronde@kergis.com>> wrote:
> >
> >     On Wed, Mar 05, 2025 at 09:16:57PM +0100, tlaronde@kergis.com
> <mailto:tlaronde@kergis.com> wrote:
> >     > On Wed, Mar 05, 2025 at 07:11:02PM +0100, tlaronde@kergis.com
> <mailto:tlaronde@kergis.com> wrote:
> >     > > I need to update the documentation about the building (one needs
> to
> >     > > bind above the 9front hier, but also to get plan9front/firmware,
> and
> >     > > to build and install brekky).
> >     > >
> >     > > But it also uses ftq.
> >     >
> >     > BTW, execac is missing also.
> >
> >     No: here ./sys/src/cmd/execac.c; needs simply to be compiled.
> >
> >     > >
> >     > > If I'm not mistaken, the git master has an unchanged mkfile
> relating
> >     > > to several flavors (ftq{15,31,63}) but is marked as broken.
> >     > >
> >     > > Do you compile it under APE?
> >     > >
> >     > > On Mon, Mar 03, 2025 at 07:44:47PM -0800, ron minnich wrote:
> >     > > > I am now able to run the HPC FTQ benchmark and get results,
> first time
> >     > > > since 2011.
> >     > > >
> >     > > > The results are very, very good on my T420. Next step, see how
> it goes on a
> >     > > > server class machine.
> >     > > >
> >     > > > If anyone wants to help out, the rebase would be most welcome,
> as would
> >     > > > testing of your choice.
> >     > > >
> >     > > > Taking a trap on an AC still does not work. I get around that
> by making
> >     > > > sure traps won't happen but ... would be nice to fix it.
> >     > > >
> >     > > > In NIX, we had a new rfork type which would let a process flip
> itself onto
> >     > > > an AC; it would be useful to bring that over.
> >     > > >
> >     > > > Lots to do, whoever wants to help, we're open for business.
> >     > >
> >     > > --
> >     > > Thierry Laronde <tlaronde +AT+ kergis +dot+ com>
> >     > >              http://www.kergis.com/ <http://www.kergis.com/>
> >     > >             http://kertex.kergis.com/ <http://kertex.kergis.com/
> >     > > Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006
> F40C
> >     >
> >     > --
> >     >         Thierry Laronde <tlaronde +AT+ kergis +dot+ com>
> >     >                      http://www.kergis.com/ <
> http://www.kergis.com/>
> >     >                     http://kertex.kergis.com/ <
> http://kertex.kergis.com/>
> >     > Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006
> F40C
> >
> >     --
> >             Thierry Laronde <tlaronde +AT+ kergis +dot+ com>
> >                          http://www.kergis.com/ <http://www.kergis.com/>
> >                         http://kertex.kergis.com/ <
> http://kertex.kergis.com/>
> >     Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C
> >
> >     ------------------------------------------
> >     9fans: 9fans
> >     Permalink:
> https://9fans.topicbox.com/groups/9fans/Tc82cdeb7e597b9d2-M39192ec6eef3979dd0ea7579
> <
> https://9fans.topicbox.com/groups/9fans/Tc82cdeb7e597b9d2-M39192ec6eef3979dd0ea7579
> >
> >     Delivery options:
> https://9fans.topicbox.com/groups/9fans/subscription <
> https://9fans.topicbox.com/groups/9fans/subscription>
> >
> > *9fans <https://9fans.topicbox.com/latest>* / 9fans / see discussions <
> https://9fans.topicbox.com/groups/9fans> + participants <
> https://9fans.topicbox.com/groups/9fans/members> + delivery options <
> https://9fans.topicbox.com/groups/9fans/subscription> Permalink <
> https://9fans.topicbox.com/groups/9fans/Tc82cdeb7e597b9d2-M90f81cabe64c4d4bcdcfd5c7

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tc82cdeb7e597b9d2-M4d418c33e9bb34bae86e6ee5
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 17717 bytes --]

Re: [9fans] NIX this evening

[Jacob Moody]

On 3/6/25 15:07, ron minnich wrote:
> Jacob re the rebase, thank you, it works in qemu and on my t420.
> 
> I'm thinking to just set my 9front head to what you've done, push it to my fork, and proceed from there. Do you see any reason not to? 

Sure by all means.

> 
> Where, ultimately, might we want NIX to land?
> 
> I need to start turning the dial down on debug prints, to start.

I think it depends on what the goals are here, I assume you're somewhat interested in having a conversation about getting
nix in to 9front, so I'll start from there. Here's what I would suggest as the path forward for that and some followup questions.

1. You'll need to squash your changes in to a smaller organization of patches that can be reviewed, the current commit list is a bit messy
        and does not follow our conventions for commit messages.

2. You'll need to make a case as to what the practical benefits are from having this capability, it seems like you've gotten somewhere with
        the ftq benchmarks, which is great, but you'll need to put things in terms of practical benefit. What is a program on the system which
        would benefit from having a core exclusive to itself? How can we prove that? Adding stuff to the Proc struct has a high impact and typically
        should be accompanied by a decently useful addition.

3. Everything right now is specific to pc64, and I think if this is a general capability going forward, we're going to need this on the other
        architectures that we support. At the very least arm64. I don't know if I would call this a requirement for getting nix merged but
        it should be something that would be a close goal following an initial merge if not.

4. For now at least, I would suggest removing the debug prints. The question regarding on how to go forward with debug prints in general is
        a good question, and something we can discuss but the discussion of nix and the discussion on debug prints are two separate discussions
        (and ideally two separate patches). To this end I would perhaps be partial to having some sort of additional file (/dev/kdebug?) that
        would serve some ring buffer that can be enabled with a write and would serve the results. (Think /net/log). This would be a bit more costly
        compared to being able to #ifdef them out but I think in this case it may be worth it.

Once you feel like you've got an organized set of diffs, the code cleaned up, and some sort of data to make an argument I would say post it over on
the 9front list. Or perhaps pop your head in on irc or one of our jitsi calls to talk it out in real time.

In general, and in particular with large impact changes like this, expect a lot of discussion on implementation, organization, and interface for these
patches if you want to go forward with arguing for their inclusion in 9front. What I tend to do is regularly review the "big diff" against upstream
and check that extra stuff hasn't snuck in.

Stuff like:
https://github.com/majiru/9front/compare/front...nix#diff-3530d7439c30d8e9125572d4c7eb0f42ca56b6adb8b069c7ce08c023c6067e48
https://github.com/majiru/9front/compare/front...nix#diff-4fac6b341748f453f31ecd0d99acc52e6069bef0d85f51200d3a498f31acc9a0R20
https://github.com/majiru/9front/compare/front...nix#diff-4fac6b341748f453f31ecd0d99acc52e6069bef0d85f51200d3a498f31acc9a0R43

You've got some files which are lacking trailing newlines at the very end of the file as well that you'll want to clean up.

The short of it is now that you've got things to a working state, I'd start cleaning stuff up, and start asking people to review
these cleaned up version to get feedback on the implementation. If you agree that this is where you're at with this.

> 
> on the original NIX, as we were in an HPC mindset, we made the only TC core 0, and all other cores ACs. 
> 
> I am wondering about a boot-time variable, such that, if not set, there are no ACs; and, if set, it means "all cores from this number up" are ACs.

Some sort of plan9.ini setting, maybe just a list of core numbers that you want to be AC's? I'm thinking something that would allow you to set a specific
list of cores. If for example your intel chip makes every odd numbered chip an E core, you may want to interleave them.

> 
> Also ... re debugging ... do you have some way of controlling, on a fairly fine basis, when and how to print debug messages? 

I ended up addressing this in the above list.

> 
> jmk had done something for 9k, which we also used on blue gene and then NIX, not sure when (2005? Charles, do you recall?) that worked like this:
> in, e.g., pc64, you have a dbgflg section. You could define a single letter for a subsystem. So, e.g., 
> dbgflg
>     acore 'c'
>     tcore 'c'
>     ioapic 'I'
> 
> There was a macro, DBG: DBG(...) 
> DBG acts like print if the dbgflg is set FOR THAT FILE.
> 
> This all gets munged by awk and friends such that each .c can check dbgflg[_DBGC_] to see whether debug prints are enabled. That's all DBG is.
> 
> You can make all debugging go away by defining a variable to be 0 and letting the linker do the elision (that's one variant of the definition of the macros, see https://github.com/rminnich/nix-os/blob/regen/sys/src/nix/k10/dat.h#L409 <https://github.com/rminnich/nix-os/blob/regen/sys/src/nix/k10/dat.h#L409>. Note a typical jmk comment: horrid :-)
> 
> long story short, you could set debug flags in the command line or in plan9.ini, and DBG would be enabled or not in the various subsystems. It was a very easy way to turn debug on and off on a per-boot-time basis.
> 
> It was nice, but it seems to have been lost in most plan 9 kernels. 
> 
> What do people do now in legacy/9front/whatever? 
> 
> Finally, for those trying to build NIX, no binds needed. git clone the repo of your choice, check out the branch, cd sys/src/9/pc64, and mk.
> 
> Finally, ... coders welcome. The level of things to do is WAY less daunting now that we are sort of working, and part of the goal of bringing NIX back is to suck people in to working on the kernel.
> 
> thanks
> 
> 
> On Wed, Mar 5, 2025 at 1:57 PM <tlaronde@kergis.com <mailto:tlaronde@kergis.com>> wrote:
> 
>     On Wed, Mar 05, 2025 at 09:16:57PM +0100, tlaronde@kergis.com <mailto:tlaronde@kergis.com> wrote:
>     > On Wed, Mar 05, 2025 at 07:11:02PM +0100, tlaronde@kergis.com <mailto:tlaronde@kergis.com> wrote:
>     > > I need to update the documentation about the building (one needs to
>     > > bind above the 9front hier, but also to get plan9front/firmware, and
>     > > to build and install brekky).
>     > >
>     > > But it also uses ftq.
>     >
>     > BTW, execac is missing also.
> 
>     No: here ./sys/src/cmd/execac.c; needs simply to be compiled.
> 
>     > >
>     > > If I'm not mistaken, the git master has an unchanged mkfile relating
>     > > to several flavors (ftq{15,31,63}) but is marked as broken.
>     > >
>     > > Do you compile it under APE?
>     > >
>     > > On Mon, Mar 03, 2025 at 07:44:47PM -0800, ron minnich wrote:
>     > > > I am now able to run the HPC FTQ benchmark and get results, first time
>     > > > since 2011.
>     > > >
>     > > > The results are very, very good on my T420. Next step, see how it goes on a
>     > > > server class machine.
>     > > >
>     > > > If anyone wants to help out, the rebase would be most welcome, as would
>     > > > testing of your choice.
>     > > >
>     > > > Taking a trap on an AC still does not work. I get around that by making
>     > > > sure traps won't happen but ... would be nice to fix it.
>     > > >
>     > > > In NIX, we had a new rfork type which would let a process flip itself onto
>     > > > an AC; it would be useful to bring that over.
>     > > >
>     > > > Lots to do, whoever wants to help, we're open for business.
>     > >
>     > > --
>     > > Thierry Laronde <tlaronde +AT+ kergis +dot+ com>
>     > >              http://www.kergis.com/ <http://www.kergis.com/>
>     > >             http://kertex.kergis.com/ <http://kertex.kergis.com/>
>     > > Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C
>     >
>     > --
>     >         Thierry Laronde <tlaronde +AT+ kergis +dot+ com>
>     >                      http://www.kergis.com/ <http://www.kergis.com/>
>     >                     http://kertex.kergis.com/ <http://kertex.kergis.com/>
>     > Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C
> 
>     -- 
>             Thierry Laronde <tlaronde +AT+ kergis +dot+ com>
>                          http://www.kergis.com/ <http://www.kergis.com/>
>                         http://kertex.kergis.com/ <http://kertex.kergis.com/>
>     Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C
> 
>     ------------------------------------------
>     9fans: 9fans
>     Permalink: https://9fans.topicbox.com/groups/9fans/Tc82cdeb7e597b9d2-M39192ec6eef3979dd0ea7579 <https://9fans.topicbox.com/groups/9fans/Tc82cdeb7e597b9d2-M39192ec6eef3979dd0ea7579>
>     Delivery options: https://9fans.topicbox.com/groups/9fans/subscription <https://9fans.topicbox.com/groups/9fans/subscription>
> 
> *9fans <https://9fans.topicbox.com/latest>* / 9fans / see discussions <https://9fans.topicbox.com/groups/9fans> + participants <https://9fans.topicbox.com/groups/9fans/members> + delivery options <https://9fans.topicbox.com/groups/9fans/subscription> Permalink <https://9fans.topicbox.com/groups/9fans/Tc82cdeb7e597b9d2-M90f81cabe64c4d4bcdcfd5c7>

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tc82cdeb7e597b9d2-Mfda66fdb5f902348e2d53be7
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] NIX this evening

[ron minnich]

[-- Attachment #1: Type: text/plain, Size: 4731 bytes --]

Jacob re the rebase, thank you, it works in qemu and on my t420.

I'm thinking to just set my 9front head to what you've done, push it to my
fork, and proceed from there. Do you see any reason not to?

Where, ultimately, might we want NIX to land?

I need to start turning the dial down on debug prints, to start.

on the original NIX, as we were in an HPC mindset, we made the only TC core
0, and all other cores ACs.

I am wondering about a boot-time variable, such that, if not set, there are
no ACs; and, if set, it means "all cores from this number up" are ACs.

Also ... re debugging ... do you have some way of controlling, on a fairly
fine basis, when and how to print debug messages?

jmk had done something for 9k, which we also used on blue gene and then
NIX, not sure when (2005? Charles, do you recall?) that worked like this:
in, e.g., pc64, you have a dbgflg section. You could define a single letter
for a subsystem. So, e.g.,
dbgflg
    acore 'c'
    tcore 'c'
    ioapic 'I'

There was a macro, DBG: DBG(...)
DBG acts like print if the dbgflg is set FOR THAT FILE.

This all gets munged by awk and friends such that each .c can check
dbgflg[_DBGC_] to see whether debug prints are enabled. That's all DBG is.

You can make all debugging go away by defining a variable to be 0 and
letting the linker do the elision (that's one variant of the definition of
the macros, see
https://github.com/rminnich/nix-os/blob/regen/sys/src/nix/k10/dat.h#L409.
Note a typical jmk comment: horrid :-)

long story short, you could set debug flags in the command line or in
plan9.ini, and DBG would be enabled or not in the various subsystems. It
was a very easy way to turn debug on and off on a per-boot-time basis.

It was nice, but it seems to have been lost in most plan 9 kernels.

What do people do now in legacy/9front/whatever?

Finally, for those trying to build NIX, no binds needed. git clone the repo
of your choice, check out the branch, cd sys/src/9/pc64, and mk.

Finally, ... coders welcome. The level of things to do is WAY less daunting
now that we are sort of working, and part of the goal of bringing NIX back
is to suck people in to working on the kernel.

thanks


On Wed, Mar 5, 2025 at 1:57 PM <tlaronde@kergis.com> wrote:

> On Wed, Mar 05, 2025 at 09:16:57PM +0100, tlaronde@kergis.com wrote:
> > On Wed, Mar 05, 2025 at 07:11:02PM +0100, tlaronde@kergis.com wrote:
> > > I need to update the documentation about the building (one needs to
> > > bind above the 9front hier, but also to get plan9front/firmware, and
> > > to build and install brekky).
> > >
> > > But it also uses ftq.
> >
> > BTW, execac is missing also.
>
> No: here ./sys/src/cmd/execac.c; needs simply to be compiled.
>
> > >
> > > If I'm not mistaken, the git master has an unchanged mkfile relating
> > > to several flavors (ftq{15,31,63}) but is marked as broken.
> > >
> > > Do you compile it under APE?
> > >
> > > On Mon, Mar 03, 2025 at 07:44:47PM -0800, ron minnich wrote:
> > > > I am now able to run the HPC FTQ benchmark and get results, first
> time
> > > > since 2011.
> > > >
> > > > The results are very, very good on my T420. Next step, see how it
> goes on a
> > > > server class machine.
> > > >
> > > > If anyone wants to help out, the rebase would be most welcome, as
> would
> > > > testing of your choice.
> > > >
> > > > Taking a trap on an AC still does not work. I get around that by
> making
> > > > sure traps won't happen but ... would be nice to fix it.
> > > >
> > > > In NIX, we had a new rfork type which would let a process flip
> itself onto
> > > > an AC; it would be useful to bring that over.
> > > >
> > > > Lots to do, whoever wants to help, we're open for business.
> > >
> > > --
> > > 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
> >
> > --
> >         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
> 
> --
> 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
Permalink: https://9fans.topicbox.com/groups/9fans/Tc82cdeb7e597b9d2-M90f81cabe64c4d4bcdcfd5c7
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 8081 bytes --]

Re: [9fans] NIX this evening

[tlaronde]

On Wed, Mar 05, 2025 at 09:16:57PM +0100, tlaronde@kergis.com wrote:
> On Wed, Mar 05, 2025 at 07:11:02PM +0100, tlaronde@kergis.com wrote:
> > I need to update the documentation about the building (one needs to
> > bind above the 9front hier, but also to get plan9front/firmware, and
> > to build and install brekky). 
> > 
> > But it also uses ftq.
> 
> BTW, execac is missing also.

No: here ./sys/src/cmd/execac.c; needs simply to be compiled.

> > 
> > If I'm not mistaken, the git master has an unchanged mkfile relating
> > to several flavors (ftq{15,31,63}) but is marked as broken.
> > 
> > Do you compile it under APE?
> > 
> > On Mon, Mar 03, 2025 at 07:44:47PM -0800, ron minnich wrote:
> > > I am now able to run the HPC FTQ benchmark and get results, first time
> > > since 2011.
> > > 
> > > The results are very, very good on my T420. Next step, see how it goes on a
> > > server class machine.
> > > 
> > > If anyone wants to help out, the rebase would be most welcome, as would
> > > testing of your choice.
> > > 
> > > Taking a trap on an AC still does not work. I get around that by making
> > > sure traps won't happen but ... would be nice to fix it.
> > > 
> > > In NIX, we had a new rfork type which would let a process flip itself onto
> > > an AC; it would be useful to bring that over.
> > > 
> > > Lots to do, whoever wants to help, we're open for business.
> > 
> > --
> > 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
> 
> -- 
>         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

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

Re: [9fans] NIX this evening

[tlaronde]

On Wed, Mar 05, 2025 at 07:11:02PM +0100, tlaronde@kergis.com wrote:
> I need to update the documentation about the building (one needs to
> bind above the 9front hier, but also to get plan9front/firmware, and
> to build and install brekky). 
> 
> But it also uses ftq.

BTW, execac is missing also.

> 
> If I'm not mistaken, the git master has an unchanged mkfile relating
> to several flavors (ftq{15,31,63}) but is marked as broken.
> 
> Do you compile it under APE?
> 
> On Mon, Mar 03, 2025 at 07:44:47PM -0800, ron minnich wrote:
> > I am now able to run the HPC FTQ benchmark and get results, first time
> > since 2011.
> > 
> > The results are very, very good on my T420. Next step, see how it goes on a
> > server class machine.
> > 
> > If anyone wants to help out, the rebase would be most welcome, as would
> > testing of your choice.
> > 
> > Taking a trap on an AC still does not work. I get around that by making
> > sure traps won't happen but ... would be nice to fix it.
> > 
> > In NIX, we had a new rfork type which would let a process flip itself onto
> > an AC; it would be useful to bring that over.
> > 
> > Lots to do, whoever wants to help, we're open for business.
> 
> --
> 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

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

Re: [9fans] NIX this evening

[tlaronde]

I need to update the documentation about the building (one needs to
bind above the 9front hier, but also to get plan9front/firmware, and
to build and install brekky). 

But it also uses ftq.

If I'm not mistaken, the git master has an unchanged mkfile relating
to several flavors (ftq{15,31,63}) but is marked as broken.

Do you compile it under APE?

On Mon, Mar 03, 2025 at 07:44:47PM -0800, ron minnich wrote:
> I am now able to run the HPC FTQ benchmark and get results, first time
> since 2011.
> 
> The results are very, very good on my T420. Next step, see how it goes on a
> server class machine.
> 
> If anyone wants to help out, the rebase would be most welcome, as would
> testing of your choice.
> 
> Taking a trap on an AC still does not work. I get around that by making
> sure traps won't happen but ... would be nice to fix it.
> 
> In NIX, we had a new rfork type which would let a process flip itself onto
> an AC; it would be useful to bring that over.
> 
> Lots to do, whoever wants to help, we're open for business.

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

Re: [9fans] NIX this evening

[Jacob Moody]

On 3/3/25 21:44, ron minnich wrote:
> I am now able to run the HPC FTQ benchmark and get results, first time since 2011. 
> 
> The results are very, very good on my T420. Next step, see how it goes on a server class machine.
> 
> If anyone wants to help out, the rebase would be most welcome, as would testing of your choice. 
> 
> Taking a trap on an AC still does not work. I get around that by making sure traps won't happen but ... would be nice to fix it.
> 
> In NIX, we had a new rfork type which would let a process flip itself onto an AC; it would be useful to bring that over. 
> 
> Lots to do, whoever wants to help, we're open for business.

I did a quick rebase:

https://github.com/majiru/9front/tree/nix

Didn't get a chance to test but maybe someone else can ensure that I cherry-pick'd everything correctly.


Thanks,
moody



------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tc82cdeb7e597b9d2-M3b78e6f3002f5b7cb9cce8f1
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[9fans] NIX this evening

[ron minnich]

[-- Attachment #1: Type: text/plain, Size: 836 bytes --]

I am now able to run the HPC FTQ benchmark and get results, first time
since 2011.

The results are very, very good on my T420. Next step, see how it goes on a
server class machine.

If anyone wants to help out, the rebase would be most welcome, as would
testing of your choice.

Taking a trap on an AC still does not work. I get around that by making
sure traps won't happen but ... would be nice to fix it.

In NIX, we had a new rfork type which would let a process flip itself onto
an AC; it would be useful to bring that over.

Lots to do, whoever wants to help, we're open for business.

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tc82cdeb7e597b9d2-M59df0756eefeb2c057c08760
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 1430 bytes --]

[9fans] nix this evening

[ron minnich]

[-- Attachment #1: Type: text/plain, Size: 341 bytes --]

I've added the struct offset generator, updated nix.s with proper offsets,
still trying to understand the gpf.

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T46bf984700e20849-Md74c41a60b8b035b5613db70
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 814 bytes --]