On 3/8/25 03:03, tlaro...@kergis.com wrote: > On Fri, Mar 07, 2025 at 01:09:30PM -0600, Jacob Moody wrote: >> On 3/7/25 06:10, tlaro...@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
