[WIP] Add concept of family with chromebook-gru #62
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This is not exactly to my liking, since this will always import a bunch of unrelated files, but this is good enough for now...
This is a convenience thing. The earlier it happens, the less spam in the logs. Additionally, this would allow use of those things in stage-1. The main useful thing is bluetooth, for a bluetooth keyboard.
This makes the boot faster since it doesn't wait for something that cant't happen
samueldr
changed the title
samueldr
added
the
9. status: WIP
|
This is not how families will end up being implemented, see #148. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I'm not entirely sure this is a good way to do this... I'll have to think about it more before merging this.
Basically, the idea is that I want to split the description of the hardware from the implementation of said hardware. Ideally, all the description should be extractable from the source files to generate fact sheets about the hardware.
So, here's how I'm thinking about implementing family-wide quirks... but this doesn't solve implementation of things for one device only.
I'm thinking, though, that this is not good since it will possibly include a bunch of files. I also would prefer something introspectable, right now there's no way to list families from the options tree, only from the filesystem, or from reading the file.
Finally, I would prefer if all "lists" of hardware, e.g. SOCs, would all use the same foundations. At the same time, I would like it if the evaluation wouldn't balloon up in time due to the wide variety of hardware.
Maybe the solution is to somehow split at the modules system the description from the implementation.
The basic gist of it is have an options tree that is isolated from the actual nixos modules system, used solely to build an attrset describing the hardware. Then, use that attrset as an input to the full blown nixos modules system.
The idea being that the
familyvalue would be already known and provided, rather than the value of an option, so inimports [ ./families + "/${hardware.family}.nix" ];, the family is not dependent on the currently being built options tree.Such a solution could be used for SOCs too.
The only issue I can see with this approach is that the list of acceptable values for e.g. SOCs or Families is not known at run-time if we rely solely on files on the filesystem. So, this wouldn't in itself allow building a list of known options. Though, I guess that for documentation purposes, we could cheat and make the option type aware that it's a filesystem-based option list.
What if a family wants to use the values from a bigger family? Let that family handle the
imports = [ ./relative-family-file.nix ];, but more importantly, prefer not making a spaghetti of dependencies.