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 <mo...@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 <tlaro...@kergis.com <mailto: > > tlaro...@kergis.com>> wrote: > > > > > > On Wed, Mar 05, 2025 at 09:16:57PM +0100, tlaro...@kergis.com > > <mailto:tlaro...@kergis.com> wrote: > > > > On Wed, Mar 05, 2025 at 07:11:02PM +0100, tlaro...@kergis.com > > <mailto:tlaro...@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
