Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[WIP] Add concept of family with chromebook-gru #62

Closed
wants to merge 3 commits into from

Conversation

@samueldr
Copy link
Member

samueldr commented Dec 4, 2019

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 family value would be already known and provided, rather than the value of an option, so in imports [ ./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.

samueldr added 3 commits Dec 4, 2019
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 samueldr changed the title Add concept of family with chromebook-gru [WIP] Add concept of family with chromebook-gru Dec 4, 2019
@samueldr samueldr marked this pull request as draft Apr 30, 2020
@samueldr
Copy link
Member Author

samueldr commented May 15, 2020

This is not how families will end up being implemented, see #148.

@samueldr samueldr closed this May 15, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

1 participant
You can’t perform that action at this time.