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. 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
