Subject: [alpine-devel] APKBUILD for kernel modules

From: Martin Galvan <[email-masked]>
Date: Tue, 23 Jan 2018 11:26:14 -0300

Hi everyone,

I'm trying to write an APKBUILD script for a package that contains a
kernel module. Since there seems to be no documentation about this,
I've been looking at some examples (the *-hardened packages), and I've
seen that, if I understood correctly, all of them set a kernel version
(_kver) and refuse to build unless linux-$_flavor/APKBUILD's pkgver
matches _kver. Every time a new kernel version comes out, the APKBUILD
has to be updated to match the new kernel version.

Is this done just to make sure the maintainer is aware of kernel
changes, and has to at least indicate so in the APKBUILD? What if we
wanted to distribute a module that worked on multiple kernel versions?

As a side note, I saw that the APKBUILDs look for
linux-$_flavor/APKBUILD in a relative path. I assume this means
they'll always run from wherever they're located in the aports tree,
but I saw that e.g.
https://git.alpinelinux.org/cgit/aports/tree/testing/ipt-netflow-hardened/APKBUILD
looks in testing for linux-$_flavor, which I didn't find. Does that
mean it'll always fail?

Finally, I saw that for failure cases there seems to be a 'die'
function that looks like perl's. Where can I find its definition? Is
it documented anywhere?

---
Unsubscribe:  [email-masked]
Help:         [email-masked]
---

---

From: Mike Crute <[email-masked]>
Date: Tue, 23 Jan 2018 15:47:51 +0000

> wanted to distribute a module that worked on multiple kernel versions?

I built a kernel module package recently and there really aren't a lot
of good docs for this. As I understood the rationale for co-versioning
modules with the kernel it's about compatibility. A module is guaranteed
to be compatible with the kernel it's built against but not necessarily
against newer or older kernels, thus it doesn't make sense for the
module to maintain it's own version but rather to adopt the version of
the kernel it's built for.

Here are the ABUILDs for the module:

https://github.com/alpinelinux/aports/blob/master/testing/aws-ena-driver-hardened/APKBUILD
https://github.com/alpinelinux/aports/blob/master/testing/aws-ena-driver-vanilla/APKBUILD
 
> looks in testing for linux-$_flavor, which I didn't find. Does that

You should always use the kernel out of the main tree and use relative
paths to make sure you always get that kernel. The ABUILD you linked is
will only ever run those tests when it's located in the main tree which
strikes me as broken.
 
> function that looks like perl's. Where can I find its definition? Is

That's defined in the abuild command itself which also defines the
default methods for your ABUILD along with other utility functions:

https://git.alpinelinux.org/cgit/abuild/tree/abuild.in#n103

---

---

From: Martin Galvan <[email-masked]>
Date: Tue, 23 Jan 2018 16:34:35 -0300

> the kernel it's built for.

I understand. I thought a APK package would do something for me like
packages generated by dkms-mkdeb do: give the module sources to the
user, then rebuild the module in the target system for its running
kernel. Now I understand they're designed for distributing binaries.
What it's not fully clear to me is how the module binaries are
distributed. What if a user with an older kernel updates their aports
tree, then tries to apk add a module package? How does the apk
machinery know which binaries to provide?

---

---

From: Nils Andreas Svee <[email-masked]>
Date: Tue, 23 Jan 2018 21:10:35 +0100

IIRC the module package depends on the exact version of the kernel it's built for. I'd assume apk would try to update the kernel package to the latest version.

Best Regards
Nils

---

---

From: "A. Wilcox" <[email-masked]>
Date: Tue, 23 Jan 2018 17:36:33 -0600

On 01/23/18 13:34, Martin Galvan wrote:
> kernel.

If only.

> machinery know which binaries to provide?

I'm planning on fixing APK to handle kernel stuff better, because it's
pretty terrible right now; you can really wedge a system bad if you
upgrade the kernel package unknowingly (via `apk upgrade -qa` or such)
and then add a module package.

Best,
--arw

-- 
A. Wilcox (awilfox)
Project Lead, Adélie Linux
http://adelielinux.org