How to maintain kernel-source packages on OBS?
Hi, I'm looking into maintaining a kernel based on out-of-tree patchset[1] on the openSUSE's build service (OBS) with Fredrik. While I work with kernel-source regularly, I have no idea on the process or publish/release the kernel. From the openSUSE:Kernel git[2] documentation and my understanding it goes down to: git clone https://github.com/openSUSE/kernel-source/ cd kernel-source git checkout $BRANCH # stable or master # Do some work here ... # Create source package scripts/tar-up.sh # Upload to OBS, need --enable-debug here otherwise BTF won't be # available scripts/osc_wrapper upload --enable-debug $PROJECT Once built, user should be able add the OBS repo, and install the kernel package I suppose? Or is there any additional that has to be done on the OBS project? Also there's two kernel branch I'd be working with: scx-kernel-releases[3] which is based on the latest stable, and sched_ext[4] which is based on bpf-next[5]. And it would be great to have suggestion on how to maintain them in practice within kernel-source. Since scx-kernel-releases is based on stable, it seems rather straight forward to maintain. I'd fork from the kernel-source's stable branch, add another directory (patches.sched-ext perhaps), add the patches there, modify series.conf to include the sched-ext patches so they are applied, and update the kernel configuration in config/ accordingly. After that it should be mostly just merging from kernel-source's stable as it changes, I hope. On the other hand sched_ext being based on the development branch bpf-next seems a bit more daunting. I could base off of kernel-source's master, but then I had to take all the patches in bpf-next[5] (which includes netdev/net-next[6]) in addition to sched-ext ones, and bpf-next could change rather often. Is there a better way to do this? Could I simply grab a tarball from the sched_ext GitHub repository[4] and use it instead? Or maybe it's just not worth the effort? Feedbacks, suggestions, and pros & cons are all welcome. Thanks, Shung-Hsi Yu 1: https://lists.opensuse.org/archives/list/factory@lists.opensuse.org/message/... 2: https://en.opensuse.org/openSUSE:Kernel_git#Using_the_kernel-source_reposito... 3: https://github.com/sched-ext/scx-kernel-releases 4: https://github.com/sched-ext/sched_ext 5: https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/log/?h=for-... 6: https://kernel.googlesource.com/pub/scm/linux/kernel/git/netdev/net-next/
On Tue, May 28, 2024 at 04:45:19PM +0800, Shung-Hsi Yu wrote:
Hi,
I'm looking into maintaining a kernel based on out-of-tree patchset[1] on the openSUSE's build service (OBS) with Fredrik.
While I work with kernel-source regularly, I have no idea on the process or publish/release the kernel. From the openSUSE:Kernel git[2] documentation and my understanding it goes down to:
git clone https://github.com/openSUSE/kernel-source/ cd kernel-source git checkout $BRANCH # stable or master # Do some work here ... ... push to some kernel-source branch for future reference perhaps # Create source package scripts/tar-up.sh # Upload to OBS, need --enable-debug here otherwise BTF won't be # available scripts/osc_wrapper upload --enable-debug $PROJECT
Once built, user should be able add the OBS repo, and install the kernel package I suppose? Or is there any additional that has to be done on the OBS project?
That's enough so long as the kernel builds. See also patches.addon for maintaining patches outside of kernel-source.
Also there's two kernel branch I'd be working with: scx-kernel-releases[3] which is based on the latest stable, and sched_ext[4] which is based on bpf-next[5]. And it would be great to have suggestion on how to maintain them in practice within kernel-source.
Since scx-kernel-releases is based on stable, it seems rather straight forward to maintain. I'd fork from the kernel-source's stable branch, add another directory (patches.sched-ext perhaps), add the patches there, modify series.conf to include the sched-ext patches so they are applied, and update the kernel configuration in config/ accordingly. After that it should be mostly just merging from kernel-source's stable as it changes, I hope.
On the other hand sched_ext being based on the development branch bpf-next seems a bit more daunting. I could base off of kernel-source's master, but then I had to take all the patches in bpf-next[5] (which includes netdev/net-next[6]) in addition to sched-ext ones, and bpf-next could change rather often. Is there a better way to do this? Could I simply grab a tarball from the sched_ext GitHub repository[4] and use it instead? Or maybe it's just not worth the effort?
We also have the linux-next brach created automatically from upstream linux-next which sometimes works well, and sometimes what the automation produces fails to build. Thanks Michal
On Tue, 28 May 2024 10:45:19 +0200, Shung-Hsi Yu wrote:
Hi,
I'm looking into maintaining a kernel based on out-of-tree patchset[1] on the openSUSE's build service (OBS) with Fredrik.
While I work with kernel-source regularly, I have no idea on the process or publish/release the kernel. From the openSUSE:Kernel git[2] documentation and my understanding it goes down to:
git clone https://github.com/openSUSE/kernel-source/ cd kernel-source git checkout $BRANCH # stable or master # Do some work here ... # Create source package scripts/tar-up.sh # Upload to OBS, need --enable-debug here otherwise BTF won't be # available scripts/osc_wrapper upload --enable-debug $PROJECT
Once built, user should be able add the OBS repo, and install the kernel package I suppose? Or is there any additional that has to be done on the OBS project?
That should work. For continuous building of the same project, you can run osc_wrapper upload --no-init option, too. That's what I've been doing for my kernel in OBS home:tiwai:kernel:drm-tip repo, for example. A daily cronjob is running on my desktop, refresh and upload the repo. Some manual tweaks are needed occasionally (usually for config adjustments or the tarball creation from *-rc). FWIW, in the above case, I generate a big diff to the latest upstream, and apply it without changing series.conf at each update. If the tree isn't moving so fast, I'd possibly create fine-grained patches from commits instead.
Also there's two kernel branch I'd be working with: scx-kernel-releases[3] which is based on the latest stable, and sched_ext[4] which is based on bpf-next[5]. And it would be great to have suggestion on how to maintain them in practice within kernel-source.
Since scx-kernel-releases is based on stable, it seems rather straight forward to maintain. I'd fork from the kernel-source's stable branch, add another directory (patches.sched-ext perhaps), add the patches there, modify series.conf to include the sched-ext patches so they are applied, and update the kernel configuration in config/ accordingly. After that it should be mostly just merging from kernel-source's stable as it changes, I hope.
As Michal mentioned, patches.addon can be used for the extra patches. Then you can keep them without intervention from the upstream. The extra configurations (including the config overrides) can be put in config.addon.tar.bz2. I'm using this mechanism in my OBS home:tiwai:kernel:kasan-sle15-sp6 (or *:kasan-stable) repo, for example It's building the standard kernel with KASAN enabled for debugging. Since it's a linked package, it follows the source project update automatically and rebuilds the package accordingly. HTH, Takashi
On the other hand sched_ext being based on the development branch bpf-next seems a bit more daunting. I could base off of kernel-source's master, but then I had to take all the patches in bpf-next[5] (which includes netdev/net-next[6]) in addition to sched-ext ones, and bpf-next could change rather often. Is there a better way to do this? Could I simply grab a tarball from the sched_ext GitHub repository[4] and use it instead? Or maybe it's just not worth the effort?
Feedbacks, suggestions, and pros & cons are all welcome.
Thanks, Shung-Hsi Yu
1: https://lists.opensuse.org/archives/list/factory@lists.opensuse.org/message/... 2: https://en.opensuse.org/openSUSE:Kernel_git#Using_the_kernel-source_reposito... 3: https://github.com/sched-ext/scx-kernel-releases 4: https://github.com/sched-ext/sched_ext 5: https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/log/?h=for-... 6: https://kernel.googlesource.com/pub/scm/linux/kernel/git/netdev/net-next/
On 5/28/24 10:45, Shung-Hsi Yu wrote:
Hi,
I'm looking into maintaining a kernel based on out-of-tree patchset[1] on the openSUSE's build service (OBS) with Fredrik.
Hello Takashi, Michal, Shung-Hsi, I'm joining Shung-Hsi in the effort of creating and maintaining an unofficial kernel package with sched-ext enabled (pluggable CPU schedulers). So far I was able to get it build in OBS, basing the code on the master branch at kernel-source (specifically, the sync with v6.10-rc5 at the master branch from last Sunday) and applying one single 33 MB jumbo diff that brings in the entire bpf-next and the sched-ext patch set. I'm adding my notes below; I expect this will have to be done weekly, as the sched-ext patch set is evolving. I have further questions, since I'd like this OBS project to be the reference sched-ext build in openSUSE for Shung-Hsi, myself, and others to try out and experiment with writing CPU schedulers. 1. QUESTION: VANITY NAME FOR THE KERNEL RPM 2. QUESTION: PROGRESSIVE PACKAGE VERSIONING 3. QUESTION: VANITY NAME FOR THE OBS PROJECT 4. QUESTION: PAGE ON THE OPENSUSE WIKI 5. RECIPE I'VE USED FOR THE SCHED-EXT BUILD 6. REGARDING PATCHES.ADDON 1. QUESTION: VANITY NAME FOR THE KERNEL RPM My branch is currently a fork of master at kernel-source, and I've simply added one more patch to series.conf (albeit a large one), but haven't touched anything else. As a result, the produced RPM is called kernel-default (well, there are others, but this is the one I'll advertise). I'd like it to be called "kernel-scx" instead. How can I do that? I'm aware that the "default" suffix comes from the name of the kernel flavor, specifically the file config/x86_64/default which is the config. How to get it produce an RPM called "kernel-scx"? Should I create a new config and call it config/x86_64/scx? 2. QUESTION: PROGRESSIVE VERSIONING The kernel-scx package will evolve rapidly; I'd say a new build every Monday or so. What's the way to manage package versions in a case like that? My objective would be that people with that repo enabled in zypper would be able to see that there's a more recent build available than the one they have currently installed. How can I make sure that a newer build has a higher version than older ones? I'm not even sure the package I created has a version at all. Maybe it's as simple as editing the spec file by hand? 3. QUESTION: VANITY NAME FOR THE OBS PROJECT Shung-Hsi has already asked for this at the Factory mailing list, link to the thread is https://lists.opensuse.org/archives/list/factory@lists.opensuse.org/thread/6... Michal Suchánek replied that assigning an OBS "namespace" is premature, but I would argue that Shung-Hsi and I have the required skills and necessary motivation to maintain such project. There is also possibly a third person, Fredrik, who actually is the first person in openSUSE who actually packaged a kernel with sched-ext enabled, although I still have to talk to him. To clarify the context, this won't be an official openSUSE Tumbleweed package but... it's as serious as it can be for being an unofficial one, if that makes sense. Multiple times during the upstream kernel discussion we (sched-ext supporters) were told to keep the patches out of tree. I was hoping that at least in our home distro we could have something more than a package under our respective OBS home projects like home:ggherdovich. Given the desire I just expressed, is there something in the set of openSUSE's processes that can lead to a vanity name for the OBS sched-ext enabled kernel? 4. PAGE ON THE OPENSUSE WIKI I would like to create and maintain a page at the openSUSE wiki on how to install the sched-ext kernel and write custom schedulers. What do you think is the more appropriate namespace for it? From https://en.opensuse.org/Help:Namespace I've learned that the namespaces Main, SDB and Portal are subject to review, but I can't find what are the expected standards and requirements to pass the review. I've seen there's a https://en.opensuse.org/Kernel namespace under which "sched-ext" may fit, but again it's the first time I'm creating a wikipage and realize I'm unfamiliar with the process. Another interesting place seems to be https://en.opensuse.org/Portal:Kernel but I couldn't tell how it differs from the aforementioned "Kernel" namespace. Do you have any suggestion, or can direct me to a better place to ask this? 5. RECIPE I'VE USED FOR THE SCHED-EXT BUILD Since master at kernel-source as of last Sunday is sync'ed with v6.10-rc5, get the diff between v6.10-rc5 and latest sched-ext: cd $LINUX_GIT git remote add sched_ext git://git.kernel.org/pub/scm/linux/kernel/git/tj/sched_ext.git git fetch --tags sched_ext for-6.11 git checkout FETCH_HEAD git checkout -b sched_ext git diff v6.10-rc5 sched_ext > /tmp/sched_ext.patch The sched_ext.git repo above has two principal branches: * sched_ext-base: this is the base onto which to rebase the sched_ext series, and essentially contain all bpf-next. * for-6.11: the actual sched_ext series, which adds 30 or so patches on top of sched_ext-base Now I'm adding the sched_ext patch above to my fork for kernel-source master. Assume the patch /tmp/sched_ext.patch has the appropriate headers; I actually added them directly editing the patch file. cd $KERNEL_SOURCE ./scripts/tar-up.sh && ./scripts/sequence-patch.sh --rapid cd tmp/current quilt import -P patches.suse/sched_ext.patch /tmp/sched_ext.patch quilt push cd $KERNEL_SOURCE # edit series.conf, put patches.suse/sched_ext.patch at the end cd tmp/current ../../scripts/refresh_patch.sh patches.suse/sched_ext.patch ./run_oldconfig.sh -y ./run_oldconfig.sh --new-config-option-yes CONFIG_SCHED_CLASS_EXT cd $KERNEL_SOURCE git status git add -A scripts/log ./scripts/tar-up.sh && ./scripts/sequence-patch.sh --rapid Note the part where I use run_oldconfig.sh from the scratch area to update the kernel config (sched_ext.patch includes the whole bpf-next and the config changes quite a lot), and then enable CONFIG_SCHED_CLASS_EXT explicitely. After committing all that to git, osc_wrapper would complain with "kernel-source does not match your current HEAD", so I'm running again tar-up.sh; I'm not sure if that's strictly necessary. Now I can finally submit for building: ./scripts/osc_wrapper upload --enable-debug home:ggherdovich:sched-ext-4:kernel-scx The project is https://build.opensuse.org/project/show/home:ggherdovich:sched-ext-4:kernel-... but it's a throwaway, I'm not fully confident the kernel works, I haven't test it yet; at least it builds without errors. 6. REGARDING PATCHES.ADDON Takashi above is suggesting to use patches.addon, and I was very interested in that because his home:tiwai:kernel:drm-tip project is very similar to what we're trying to do with sched-ext. So I put my patch in kernel-source/patches.addon.tar.bz2, but tar-up.sh would replace it with an empty archive. Michal Suchánek explained me the patches.addon method is not something you use with tar-up.sh, as that's specific to the git workflow (I think?). Patches.addon is something for when you use osc and a workflow entirely based on OBS. I'm unfamiliar with this workflow but it looks very convenient so I'll have to look at that. Giovanni
On Jun 27 2024, Giovanni Gherdovich wrote:
6. REGARDING PATCHES.ADDON
Takashi above is suggesting to use patches.addon, and I was very interested in that because his home:tiwai:kernel:drm-tip project is very similar to what we're trying to do with sched-ext. So I put my patch in kernel-source/patches.addon.tar.bz2, but tar-up.sh would replace it with an empty archive.
tar-up.sh only picks up patches that are mentioned in series.conf, so you need to add them there before running tar-up.sh.
Michal Suchánek explained me the patches.addon method is not something you use with tar-up.sh
You can use that quite well, see devel:RISCV:Factory:Contrib:StarFive:VisionFive2/kernel-source for an example. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different."
On 27. 06. 24, 11:41, Andreas Schwab wrote:
On Jun 27 2024, Giovanni Gherdovich wrote:
6. REGARDING PATCHES.ADDON
Takashi above is suggesting to use patches.addon, and I was very interested in that because his home:tiwai:kernel:drm-tip project is very similar to what we're trying to do with sched-ext. So I put my patch in kernel-source/patches.addon.tar.bz2, but tar-up.sh would replace it with an empty archive.
tar-up.sh only picks up patches that are mentioned in series.conf, so you need to add them there before running tar-up.sh.
Michal Suchánek explained me the patches.addon method is not something you use with tar-up.sh
You can use that quite well, see devel:RISCV:Factory:Contrib:StarFive:VisionFive2/kernel-source for an example.
Or use patches.addon as designed: 1) link kernel-source from the preferred kernel source into your project 2) instead of the above, add a "series" (no ".conf" suffix there) file to patches.addon. I.e. no tar-up at all. 3) Only upload your tared patches.addon.tar.bz2 (and/or config.addon.tar.bz2). If you use tar-up, you don't need patches.addon. -- js suse labs
On Jun 27 2024, Jiri Slaby wrote:
If you use tar-up, you don't need patches.addon.
But it works nevertheless, and is much more convenient. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different."
On 27. 06. 24, 12:09, Andreas Schwab wrote:
On Jun 27 2024, Jiri Slaby wrote:
If you use tar-up, you don't need patches.addon.
But it works nevertheless, and is much more convenient.
I mean, one would put the patches into patches.suse, if they use tar-up. patches.addon were designed for a different workflow. But whatever is convenient for you ;). -- js suse labs
On Jun 27 2024, Jiri Slaby wrote:
I mean, one would put the patches into patches.suse, if they use tar-up.
No, that would constantly create conflicts. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different."
On 6/27/24 11:59, Jiri Slaby wrote:
On 27. 06. 24, 11:41, Andreas Schwab wrote:
You can use that quite well, see devel:RISCV:Factory:Contrib:StarFive:VisionFive2/kernel-source for an example.
Or use patches.addon as designed: 1) link kernel-source from the preferred kernel source into your project 2) instead of the above, add a "series" (no ".conf" suffix there) file to patches.addon. I.e. no tar-up at all. 3) Only upload your tared patches.addon.tar.bz2 (and/or config.addon.tar.bz2).
Thanks Andreas and Jiří for your advices. Jiří: right, you need to link (which as I'm learning, it's an OBS term) to the original kernel-source package in order to use patches.addon. It does say so at the kernel-source/README.SUSE file, section "How to add custom patches", but initially I didn't understand that "linking" is an essential part of the process. Now that you're saying it, I'm looking it up at the OBS manual and it's explained at 5.4.3.1 "Linking a Package", so I can try doing it. https://openbuildservice.org/help/manuals/obs-user-guide/cha.obs.basicworkfl... The part I'm not fully convinced about is updating the kernel config, if I were to use patches.addon. My diff with respect to kernel-source is very large, and without run_oldconfig.sh I wouldn't know where to start. That diff is adding and changing lots of config options. So my thought process was like: I need to use run_oldconfig.sh, otherwise my build would fail since "make syncconfig" adds/changes many options and the build is aborted. To use run_oldconfig.sh, I need a kernel tree, which means I have to use tar-up.sh. So no patches.addon for me. Giovanni
Finally, I have the opportunity to play the best slot machines in Australia thanks to this cool site that I recently found aussie96 - https://aussie96.casino/ . I advise you to try to play on this site, because I am sure that on this site you will be able to enjoy the gameplay to the fullest! Goodbye,
participants (7)
-
Andreas Schwab -
Giovanni Gherdovich -
Jiri Slaby -
Michal Suchánek -
monkawlac＠proton.me -
Shung-Hsi Yu -
Takashi Iwai