-
Notifications
You must be signed in to change notification settings - Fork 81
Simplify kernel directory logic and rework hv-daemons #3565
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
Conversation
sdk_container/src/third_party/coreos-overlay/app-emulation/hv-daemons/hv-daemons-6.12.61.ebuild
Outdated
Show resolved
Hide resolved
f6b334d to
70603eb
Compare
ader1990
left a comment
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.
Tested locally with AMD64 Hyper-V both generations, everything working as expected (vss and kvp daemons). Networking data is also present in the Hyper-V Manager.
Having too many variables is confusing, so use the ones already provided by upstream. linux-info.eclass uses KERNEL_DIR (if set) as the kernel sources directory and sets KV_DIR to that for use elsewhere. If KERNEL_DIR is unset, it checks the /usr/src/linux symlink. While we could rely on the symlink, we want to be sure that coreos-modules and coreos-kernel are built against the matching kernel version. KV_OUT_DIR is the kernel output directory. It is automatically set by linux-info.eclass, and it will never leave it empty. Signed-off-by: James Le Cuirot <jlecuirot@microsoft.com>
It doesn't make any sense because there is no 9999 version of coreos-sources. Signed-off-by: James Le Cuirot <jlecuirot@microsoft.com>
It's essentially a standalone userspace project that happens to live within the kernel sources. It should not be built like the kernel. hv_fcopy_daemon was dropped upstream. Signed-off-by: James Le Cuirot <jlecuirot@microsoft.com>
The hv-daemons package has been adjusted instead. Signed-off-by: James Le Cuirot <jlecuirot@microsoft.com>
It's unnecessary and looks weird. Signed-off-by: James Le Cuirot <jlecuirot@microsoft.com>
70603eb to
5a0e40a
Compare
|
Thanks for this PR, I think it needs a follow-up item to update the automation here: scripts/.github/workflows/kernel-apply-patch.sh Lines 40 to 46 in b1e362e
This currently breaks the CI: #3589 Should we just copy the "previous" ebuild to the "new" ebuild? |
|
Am I right in thinking the GHA job is kicked off from main but kernel-apply-patch.sh is run from each branch? |
Yes, I think as it fails on |
Simplify kernel directory logic and rework hv-daemons
Having too many variables is confusing, so use the ones already provided by upstream. linux-info.eclass uses
KERNEL_DIR(if set) as the kernel sources directory and sets KV_DIR to that for use elsewhere. IfKERNEL_DIRis unset, it checks the /usr/src/linux symlink. While we could rely on the symlink, we want to be sure that coreos-modules and coreos-kernel are built against the matching kernel version.KV_OUT_DIRis the kernel output directory. It is automatically set by linux-info.eclass, and it will never leave it empty.I'd like to follow up these changes with a rename of sys-kernel/coreos-* to flatcar, but I'll do that in a separate step.
hv-daemons essentially a standalone userspace project that happens to live within the kernel sources. It should not be built like the kernel.
How to use
Nothing to use. These are purely build changes.
Testing done
I have built an image manually. Jenkins CI entirely passed with a run that included azure.
changelog/directory (user-facing change, bug fix, security fix, update) -- N/A/bootand/usrsize, packages, list files for any missing binaries, kernel modules, config files, kernel modules, etc.