| 30 Jun 2022 |
 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 |
| Alyssa Ross | e.g. https://github.com/NixOS/nixos-hardware/tree/master/microsoft/surface/kernel | 08:36:27 |
| matthewcroughan - nix.how | The user wants a working visionfive today | 08:36:28 |
| matthewcroughan - nix.how | and we don't have a way of expressing that if we put it into nixos-hardware | 08:36:36 |
| Alyssa Ross | and they can get that by using nixos-hardware! | 08:36:44 |
| matthewcroughan - nix.how | this PR works right now, the only way to satisfy the nixpkgs semantics is to break this PR | 08:36:49 |
| matthewcroughan - nix.how | a broken PR, that can only be unbroken by telling the user to use nixos-hardware | 08:37:02 |
| Alyssa Ross | the user would have to know to configure NixOS to use the custom vendor kernel anyway, wouldn't they? | 08:37:41 |
| matthewcroughan - nix.how | so if we follow the unspoken policy of not using vendor kernels in nixpkgs, then we cannot provide a working expression that just works without additional imports and instructions | 08:37:46 |
| Alyssa Ross | you could provide a flake that works! | 08:38:08 |
