| 30 Jun 2022 |
 matthewcroughan - nix.how | In reply to @dramforever:matrix.org
there could be a visionfive.nix module that adds things like config.system.build.flashBootloader And that could be added to the linux_visionfive pr right? | 08:25:34 |
| matthewcroughan - nix.how | I suppose I'll work on that, and add it to nixpkgs when done | 08:25:50 |
| matthewcroughan - nix.how | but that requires merging https://github.com/NixOS/nixpkgs/pull/168826 | 08:26:01 |
| matthewcroughan - nix.how | I would really rather see it merged now, since it works so well | 08:26:07 |
| matthewcroughan - nix.how | I could make the argument that it should be merged now, so that work like this can be done on top of this PR, but what do you think? | 08:26:43 |
| matthewcroughan - nix.how | If we don't merge it, it just gets stale, and work cannot be done. The PR works fine. | 08:27:07 |
| matthewcroughan - nix.how | If it were merged now, I'd work on adding wifi, and then the flashBootloader script, in my own PR. | 08:27:54 |
| matthewcroughan - nix.how | It is a real question whether stuff like this is best placed in nixpkgs itself, or in a flake these days though. | 08:29:36 |
 Alyssa Ross | I think at least some of it belongs in nixos-hardware | 08:30:06 |
| matthewcroughan - nix.how | It means that the visionfive would be unique in having that flashBootloader script, which handles a lot for the user | 08:30:40 |
 dramforever | I think it brings in a bit too much random stuff. There's a master version of OpenSBI, a fork of U-Boot by NickCao, StarFive's entire fork of Linux | 08:31:07 |
| matthewcroughan - nix.how | that'll settle though, so it won't be a problem | 08:31:26 |
| dramforever | I think it's best to just start working on stuff in a flake | 08:31:52 |
 fufexan | the kernel is fine in nixpkgs imo, as that's where people expect to find kernels | 08:32:37 |
| fufexan | but the rest could be developed in a flake | 08:32:44 |
| fufexan | it's much easier to move fast in a flake than in nixpkgs | 08:32:55 |
| matthewcroughan - nix.how | vendor kernels being in nixpkgs does sound weird though if you think about it | 08:33:05 |
| matthewcroughan - nix.how | nixos-hardware wants to be a collection of nix code that you import to circumvent hardware quirks | 08:33:19 |
| matthewcroughan - nix.how | requiring a vendor kernel (custom kernel supplied by weirdos that continue to make the ecosystem more broken) is a hardware quirk | 08:33:47 |
| matthewcroughan - nix.how | so it would make sense to start polluting nixos-hardware, rather than nixpkgs, with that stuff | 08:34:25 |
| dramforever | I'm not sure how StarFive feels about upstreaming random stuff. They already upstreamed their GPIO/clock/reset drivers to mainline, but it seems that they updated it in their fork and added more stuff | 08:34:31 |
| matthewcroughan - nix.how | In reply to @dramforever:matrix.org
I'm not sure how StarFive feels about upstreaming random stuff. They already upstreamed their GPIO/clock/reset drivers to mainline, but it seems that they updated it in their fork and added more stuff It's probably more of a case of visionfive being in rapid development | 08:34:53 |
| matthewcroughan - nix.how | so it'll probably settle | 08:34:58 |
| dramforever | It might be a good idea to check out exactly what StarFive did with their linux fork | 08:35:03 |
| matthewcroughan - nix.how | Alyssa Ross: can we put it in nixos-hardware, then fetch it in nixpkgs? | 08:35:32 |
| Alyssa Ross | No, that would be IFD | 08:35:48 |
| matthewcroughan - nix.how | what we actually want to express is "Here's a vendor kernel that we need to use for now" | 08:35:54 |
| matthewcroughan - nix.how | because otherwise, this PR will take a year to merge, as the work is upstreamed to linux proper | 08:36:07 |
| Alyssa Ross | Yeah, that's what nixos-hardware is for. | 08:36:09 |
| matthewcroughan - nix.how | Right, but that's not what we want to express to the user. | 08:36:23 |
