~alpine/devel

4 4

[alpine-devel] APKBUILD for kernel modules

Martin Galvan <omgalvan.86@gmail.com>
Details
Message ID
<CAN19L9GRSPJinpOC1NxHhv4gbuEf=GWF9B03xfP4aBWPYZN+zg@mail.gmail.com>
Sender timestamp
1516717574
DKIM signature
missing
Download raw message
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:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Mike Crute <mike@crute.us>
Details
Message ID
<20180123154751.GA10964@crute.us>
In-Reply-To
<CAN19L9GRSPJinpOC1NxHhv4gbuEf=GWF9B03xfP4aBWPYZN+zg@mail.gmail.com> (view parent)
Sender timestamp
1516722471
DKIM signature
missing
Download raw message
On Tue, Jan 23, 2018 at 11:26:14AM -0300, Martin Galvan wrote:
> 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?

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
 
> 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?

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.
 
> 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?

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


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Martin Galvan <omgalvan.86@gmail.com>
Details
Message ID
<CAN19L9GoOkiK-fCFftOKX2u_PuYqV4x57E2gFgTDCoR5=NA0sg@mail.gmail.com>
In-Reply-To
<20180123154751.GA10964@crute.us> (view parent)
Sender timestamp
1516736075
DKIM signature
missing
Download raw message
2018-01-23 12:47 GMT-03:00 Mike Crute <mike@crute.us>:
> 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.

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?


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Details
Message ID
<ca88255a-8e4b-d2f2-22f2-7e7f34234736@adelielinux.org>
In-Reply-To
<CAN19L9GoOkiK-fCFftOKX2u_PuYqV4x57E2gFgTDCoR5=NA0sg@mail.gmail.com> (view parent)
Sender timestamp
1516750593
DKIM signature
missing
Download raw message
On 01/23/18 13:34, Martin Galvan wrote:
> 2018-01-23 12:47 GMT-03:00 Mike Crute <mike@crute.us>:
>> 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.
> 
> 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.


If only.


> 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?


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
Nils Andreas Svee <me@lochnair.net>
Details
Message ID
<1516738235.3638165.1245638768.104E050B@webmail.messagingengine.com>
In-Reply-To
<CAN19L9GoOkiK-fCFftOKX2u_PuYqV4x57E2gFgTDCoR5=NA0sg@mail.gmail.com> (view parent)
Sender timestamp
1516738235
DKIM signature
missing
Download raw message
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


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Reply to thread Export thread (mbox)