-
-
Notifications
You must be signed in to change notification settings - Fork 15.3k
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
zmalllinugz: init at 5.3.8 (linux kernel version) #72714
Conversation
@GrahamcOfBorg eval |
buildInputs = [ coreutils flex bison libelf bc hostname perl]; | ||
|
||
unpackPhase = '' | ||
array=($srcs) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are not all sources unpacked by default? Could you do the additional steps in the postUnpack
as to avoid overriding the phase?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
not sure what is the best to add tar.gz as source + the config. By default default unpackPhase will try to unpack the .config and fails. Any suggestion?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
BTW: I see lot's of heuristics in the builder script. The unpackPhase, as mentioned tries to unpack several sources, but expects only one sourceDir. With the same logic, the unpackPhase could just ignore sources that do not have a known extension and pass them as they are to the next phase. Maybe I should create an issue for this. Or am I missing something? I would love to understand better this, as the documentation is bit poor in this sense. (about semantics, intentions etc.)
|
||
meta = with stdenv.lib; { | ||
description = "Smallest possible linux kernel for KVM"; | ||
longDescription = '' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems like this is a package just for yourself? In this case I don't think it belongs in Nixpkgs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well any package at the beginning is for "oneself". Hopefully it will be useful for others for any project that needs a simple kernel for VM's. As mentioned in the description this is an enabler for another project I am working on, but atm did not want to disclose too much. The build will be important to make the acceptance of the project smooth.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@FRidh any chance to continue with this? Would really appreciate it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, people's custom kernel builds should not be part of Nixpkgs.
I'll leave it open for a bit to see if there is any additional feedback.
While I agree that it is a custom kernel, I am afraid you are focusing only on the "custom" part and not on the added value. This kernel wants to be enough good to be used in any application where instead of containers for higher isolation you want to use kvm based virtual machines (Kubernetes runtimes etc.) I may have missed something, but existing kernel module based solutions make deployment considerably more complex. I am happy to discuss existing solutions but even more, I would like to grasp the philosophy of what can go in and what not. I understand that nobody wants to see garbage around here, but this is not garbage. My understanding is that the main motivation to contribute with expressions is to have at least as exchange the builds available in the cache. I just started to contribute and have a list of other tools I would like to contribute, but if the rules are not clear I think anyone would loose sooner or later the motivation. Obviously it is easier to loose motivation that to gain it. |
Don't merge yet however, have updates to the PR, but not ready to push. Thus please keep it open anyway |
Motivation for this change
Things done
sandbox
innix.conf
on non-NixOS linux)nix-shell -p nix-review --run "nix-review wip"
./result/bin/
)nix path-info -S
before and after)Notify maintainers
cc @