The state of DKMS in the Yocto community


Alex Stewart
 

Hey List,

I'm trying to work out the mysterious state of DKMS in OE-Core.

Our (NI) OE distributions rely heavily on DKMS to (un)install our ecosystem of kernel drivers at runtime across our product lines. To facilitate that, we authored a dkms_2.4.0.bb recipe [1] back in 2017, which we have carried out-of-stream since.

We tried to upstream it, and the patched rev'ed a couple of times [2]; but it seems to have never made it into a yocto release.

Though some other recipes mention DKMS passingly, I don't see anywhere that OE-Core officially supports it. Nor does my googling reveal anyone else who uses DKMS. I find that a little hard to believe, though I understand that it's probably relatively rare in the embedded space.


@all
So does anyone else on the list use DKMS in their yocto distribution? Are you maintaining a DKMS recipe out-of-stream as well?


@maintainers
If NI upgraded our DKMS recipe to a more recent version than 2.4.0 and submitted it again to OE-Core, would you accept it? If not, we will move it to our own meta layer and accept that we are unique in this regard.


[1] https://github.com/ni/openembedded-core/commit/5789a27b68d95f3840bb8c4cb0d7b28d538c9a50

[2] https://lists.openembedded.org/g/openembedded-core/message/100680

Thanks,

--
Alex Stewart
Software Engineer - NI Real-Time OS
NI (National Instruments)

alex.stewart@...


Leon Woestenberg
 

Hello Alex,

with DKMS, do you mean cross-compiling out-of-kernel modules on the
build machine (that runs the Yocto/OpenEmbedded driven build)?

Or do you mean provisioning the target with enough tools to allow
compiling out-of-kernel modules there from source?

In the first case, yes, I can share such recipe for reasonably recent releases.

Regards,

Leon.

--
Leon Woestenberg
leon@...
T: +31 40 711 42 76
M: +31 6 472 30 372

Sidebranch Embedded Systems
Eindhoven, The Netherlands
http://www.sidebranch.com

On Fri, Dec 10, 2021 at 9:58 PM Alex Stewart <alex.stewart@...> wrote:

Hey List,

I'm trying to work out the mysterious state of DKMS in OE-Core.

Our (NI) OE distributions rely heavily on DKMS to (un)install our
ecosystem of kernel drivers at runtime across our product lines. To
facilitate that, we authored a dkms_2.4.0.bb recipe [1] back in 2017,
which we have carried out-of-stream since.

We tried to upstream it, and the patched rev'ed a couple of times [2];
but it seems to have never made it into a yocto release.

Though some other recipes mention DKMS passingly, I don't see anywhere
that OE-Core officially supports it. Nor does my googling reveal anyone
else who uses DKMS. I find that a little hard to believe, though I
understand that it's probably relatively rare in the embedded space.


@all
So does anyone else on the list use DKMS in their yocto distribution?
Are you maintaining a DKMS recipe out-of-stream as well?


@maintainers
If NI upgraded our DKMS recipe to a more recent version than 2.4.0 and
submitted it again to OE-Core, would you accept it? If not, we will move
it to our own meta layer and accept that we are unique in this regard.


[1]
https://github.com/ni/openembedded-core/commit/5789a27b68d95f3840bb8c4cb0d7b28d538c9a50

[2] https://lists.openembedded.org/g/openembedded-core/message/100680

Thanks,

--
Alex Stewart
Software Engineer - NI Real-Time OS
NI (National Instruments)

alex.stewart@...




Bruce Ashfield
 

On Fri, Dec 10, 2021 at 3:58 PM Alex Stewart <alex.stewart@...> wrote:

Hey List,

I'm trying to work out the mysterious state of DKMS in OE-Core.

Our (NI) OE distributions rely heavily on DKMS to (un)install our
ecosystem of kernel drivers at runtime across our product lines. To
facilitate that, we authored a dkms_2.4.0.bb recipe [1] back in 2017,
which we have carried out-of-stream since.

We tried to upstream it, and the patched rev'ed a couple of times [2];
but it seems to have never made it into a yocto release.

Though some other recipes mention DKMS passingly, I don't see anywhere
that OE-Core officially supports it. Nor does my googling reveal anyone
else who uses DKMS. I find that a little hard to believe, though I
understand that it's probably relatively rare in the embedded space.


@all
So does anyone else on the list use DKMS in their yocto distribution?
Are you maintaining a DKMS recipe out-of-stream as well?


@maintainers
If NI upgraded our DKMS recipe to a more recent version than 2.4.0 and
submitted it again to OE-Core, would you accept it? If not, we will move
it to our own meta layer and accept that we are unique in this regard.
I used to have a DKMS recipe myself (at my previous employer), but
never submitted it, because generally speaking, there are better ways
to do things in OE.

DKMS tends to avoid proper cross compilation (which of course we
already do), or is often used to distribute proprietary code (which we
don't want to encourage), or is avoiding the need to upstream the
module code (which we also don't want to encourage). It also only
tends to be used on a subset of the architectures that have enough
memory/cpu to build on target, so by definition it is a bit more
niche.

We of course already have the ability to build modules on the target
(we have a test case in core that does just that), so what is in core
can support what DKMS needs to build on target.

I don't see this as something that makes sense in oe-core (but maybe
I'm not fully understanding the case, and where the current support is
failing), but could of course be contributed to another layer.

Cheers,

Bruce




[1]
https://github.com/ni/openembedded-core/commit/5789a27b68d95f3840bb8c4cb0d7b28d538c9a50

[2] https://lists.openembedded.org/g/openembedded-core/message/100680

Thanks,

--
Alex Stewart
Software Engineer - NI Real-Time OS
NI (National Instruments)

alex.stewart@...




--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II


Alex Stewart
 

On 12/11/21 09:24, Bruce Ashfield wrote:
On Fri, Dec 10, 2021 at 3:58 PM Alex Stewart <alex.stewart@...> wrote:
Hey List,

I'm trying to work out the mysterious state of DKMS in OE-Core.

Our (NI) OE distributions rely heavily on DKMS to (un)install our
ecosystem of kernel drivers at runtime across our product lines. To
facilitate that, we authored a dkms_2.4.0.bb recipe [1] back in 2017,
which we have carried out-of-stream since.

We tried to upstream it, and the patched rev'ed a couple of times [2];
but it seems to have never made it into a yocto release.

Though some other recipes mention DKMS passingly, I don't see anywhere
that OE-Core officially supports it. Nor does my googling reveal anyone
else who uses DKMS. I find that a little hard to believe, though I
understand that it's probably relatively rare in the embedded space.


@all
So does anyone else on the list use DKMS in their yocto distribution?
Are you maintaining a DKMS recipe out-of-stream as well?


@maintainers
If NI upgraded our DKMS recipe to a more recent version than 2.4.0 and
submitted it again to OE-Core, would you accept it? If not, we will move
it to our own meta layer and accept that we are unique in this regard.
I used to have a DKMS recipe myself (at my previous employer), but
never submitted it, because generally speaking, there are better ways
to do things in OE.

DKMS tends to avoid proper cross compilation (which of course we
already do), or is often used to distribute proprietary code (which we
don't want to encourage), or is avoiding the need to upstream the
module code (which we also don't want to encourage). It also only
tends to be used on a subset of the architectures that have enough
memory/cpu to build on target, so by definition it is a bit more
niche.
Yeah; I agree. In our case, we have several dozen drivers split across many product teams and largely distributing internally-controlled source. At this stage, it isn't feasible for us to build them all within OE - which is unfortunate.

Many of those drivers are also required to support both our OE distribution, as well as a small matrix of supported generic Linux desktop OSes. So having them manage their own DKMS packages reduces the surface area for packaging errors.

I don't expect that either of those considerations is common in the OE community.

We of course already have the ability to build modules on the target
(we have a test case in core that does just that), so what is in core
can support what DKMS needs to build on target.
I'm not sure which test case you're referencing, do you have a link or could you expand on what you mean?

I don't see this as something that makes sense in oe-core (but maybe
I'm not fully understanding the case, and where the current support is
failing), but could of course be contributed to another layer.
That's fair. Our use case is motivated more by an organizational failure than a failure of the OE tooling.


@Khem
You're maintaining the meta-oe layer; correct? Do you have any interest in a DKMS recipe?

Thanks,

--
Alex Stewart
Software Engineer - NI Real-Time OS
NI (National Instruments)

alex.stewart@...


Bruce Ashfield
 

On Mon, Dec 13, 2021 at 7:28 AM Alex Stewart <alex.stewart@...> wrote:

On 12/11/21 09:24, Bruce Ashfield wrote:
On Fri, Dec 10, 2021 at 3:58 PM Alex Stewart <alex.stewart@...> wrote:
Hey List,

I'm trying to work out the mysterious state of DKMS in OE-Core.

Our (NI) OE distributions rely heavily on DKMS to (un)install our
ecosystem of kernel drivers at runtime across our product lines. To
facilitate that, we authored a dkms_2.4.0.bb recipe [1] back in 2017,
which we have carried out-of-stream since.

We tried to upstream it, and the patched rev'ed a couple of times [2];
but it seems to have never made it into a yocto release.

Though some other recipes mention DKMS passingly, I don't see anywhere
that OE-Core officially supports it. Nor does my googling reveal anyone
else who uses DKMS. I find that a little hard to believe, though I
understand that it's probably relatively rare in the embedded space.


@all
So does anyone else on the list use DKMS in their yocto distribution?
Are you maintaining a DKMS recipe out-of-stream as well?


@maintainers
If NI upgraded our DKMS recipe to a more recent version than 2.4.0 and
submitted it again to OE-Core, would you accept it? If not, we will move
it to our own meta layer and accept that we are unique in this regard.
I used to have a DKMS recipe myself (at my previous employer), but
never submitted it, because generally speaking, there are better ways
to do things in OE.

DKMS tends to avoid proper cross compilation (which of course we
already do), or is often used to distribute proprietary code (which we
don't want to encourage), or is avoiding the need to upstream the
module code (which we also don't want to encourage). It also only
tends to be used on a subset of the architectures that have enough
memory/cpu to build on target, so by definition it is a bit more
niche.
Yeah; I agree. In our case, we have several dozen drivers split across
many product teams and largely distributing internally-controlled
source. At this stage, it isn't feasible for us to build them all within
OE - which is unfortunate.

Many of those drivers are also required to support both our OE
distribution, as well as a small matrix of supported generic Linux
desktop OSes. So having them manage their own DKMS packages reduces the
surface area for packaging errors.

I don't expect that either of those considerations is common in the OE
community.

We of course already have the ability to build modules on the target
(we have a test case in core that does just that), so what is in core
can support what DKMS needs to build on target.
I'm not sure which test case you're referencing, do you have a link or
could you expand on what you mean?
I was just referring to the kernel-devsrc package, and that it supports
both eSDK and on-target compilation of kernel modules. We have a
hello-mod that is part of the oe-tests (it is copied to the target, built
and insmod'd).

So we know that the actual build will work on the target and that all
the dependencies are in place. We just don't have any wrapping
framework around the build.

Cheers,

Bruce


I don't see this as something that makes sense in oe-core (but maybe
I'm not fully understanding the case, and where the current support is
failing), but could of course be contributed to another layer.
That's fair. Our use case is motivated more by an organizational failure
than a failure of the OE tooling.


@Khem
You're maintaining the meta-oe layer; correct? Do you have any interest
in a DKMS recipe?

Thanks,

--
Alex Stewart
Software Engineer - NI Real-Time OS
NI (National Instruments)

alex.stewart@...




--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II


Richard Purdie
 

On Fri, 2021-12-10 at 14:58 -0600, Alex Stewart wrote:
Hey List,

I'm trying to work out the mysterious state of DKMS in OE-Core.

Our (NI) OE distributions rely heavily on DKMS to (un)install our
ecosystem of kernel drivers at runtime across our product lines. To
facilitate that, we authored a dkms_2.4.0.bb recipe [1] back in 2017,
which we have carried out-of-stream since.

We tried to upstream it, and the patched rev'ed a couple of times [2];
but it seems to have never made it into a yocto release.

Though some other recipes mention DKMS passingly, I don't see anywhere
that OE-Core officially supports it. Nor does my googling reveal anyone
else who uses DKMS. I find that a little hard to believe, though I
understand that it's probably relatively rare in the embedded space.


@all
So does anyone else on the list use DKMS in their yocto distribution?
Are you maintaining a DKMS recipe out-of-stream as well?


@maintainers
If NI upgraded our DKMS recipe to a more recent version than 2.4.0 and
submitted it again to OE-Core, would you accept it? If not, we will move
it to our own meta layer and accept that we are unique in this regard.


[1]
https://github.com/ni/openembedded-core/commit/5789a27b68d95f3840bb8c4cb0d7b28d538c9a50

[2] https://lists.openembedded.org/g/openembedded-core/message/100680
Speaking for OE-Core, I don't think DKMS belongs there. I must admit I'd
forgotten what it was at first but then the memories came back.

I realise why it exists but it doesn't really model best practises or encourages
the behaviour we ideally want to see so I don't think it is a good fit for core.

Whether it might be accepted or makes sense elsewhere isn't for me to say.

Cheers,

Richard


Khem Raj
 

On Mon, Dec 13, 2021 at 4:28 AM Alex Stewart <alex.stewart@...> wrote:

On 12/11/21 09:24, Bruce Ashfield wrote:
On Fri, Dec 10, 2021 at 3:58 PM Alex Stewart <alex.stewart@...> wrote:
Hey List,

I'm trying to work out the mysterious state of DKMS in OE-Core.

Our (NI) OE distributions rely heavily on DKMS to (un)install our
ecosystem of kernel drivers at runtime across our product lines. To
facilitate that, we authored a dkms_2.4.0.bb recipe [1] back in 2017,
which we have carried out-of-stream since.

We tried to upstream it, and the patched rev'ed a couple of times [2];
but it seems to have never made it into a yocto release.

Though some other recipes mention DKMS passingly, I don't see anywhere
that OE-Core officially supports it. Nor does my googling reveal anyone
else who uses DKMS. I find that a little hard to believe, though I
understand that it's probably relatively rare in the embedded space.


@all
So does anyone else on the list use DKMS in their yocto distribution?
Are you maintaining a DKMS recipe out-of-stream as well?


@maintainers
If NI upgraded our DKMS recipe to a more recent version than 2.4.0 and
submitted it again to OE-Core, would you accept it? If not, we will move
it to our own meta layer and accept that we are unique in this regard.
I used to have a DKMS recipe myself (at my previous employer), but
never submitted it, because generally speaking, there are better ways
to do things in OE.

DKMS tends to avoid proper cross compilation (which of course we
already do), or is often used to distribute proprietary code (which we
don't want to encourage), or is avoiding the need to upstream the
module code (which we also don't want to encourage). It also only
tends to be used on a subset of the architectures that have enough
memory/cpu to build on target, so by definition it is a bit more
niche.
Yeah; I agree. In our case, we have several dozen drivers split across
many product teams and largely distributing internally-controlled
source. At this stage, it isn't feasible for us to build them all within
OE - which is unfortunate.

Many of those drivers are also required to support both our OE
distribution, as well as a small matrix of supported generic Linux
desktop OSes. So having them manage their own DKMS packages reduces the
surface area for packaging errors.

I don't expect that either of those considerations is common in the OE
community.

We of course already have the ability to build modules on the target
(we have a test case in core that does just that), so what is in core
can support what DKMS needs to build on target.
I'm not sure which test case you're referencing, do you have a link or
could you expand on what you mean?

I don't see this as something that makes sense in oe-core (but maybe
I'm not fully understanding the case, and where the current support is
failing), but could of course be contributed to another layer.
That's fair. Our use case is motivated more by an organizational failure
than a failure of the OE tooling.


@Khem
You're maintaining the meta-oe layer; correct? Do you have any interest
in a DKMS recipe?
I cant say how much maintenance work it is upfront. I have been bitten with some
hairy recipes e.g. kernel-selftest which need active maintenance for
which I might not
have time to do myself. However, looking at what Bruce explains, it
seems the value
add it not as much either, so I am less inclined to have it unless
there are others in
community who will find it useful and service it timely manner and
test it, keep it working
with all test combinations etc


Thanks,

--
Alex Stewart
Software Engineer - NI Real-Time OS
NI (National Instruments)

alex.stewart@...


Alex Stewart
 

Converging threads.

Thanks all for the feedback. It sounds like there's no appetite for a DKMS recipe, and I agree with the rationale for rejection.

I'll motion to have NI's DKMS recipe migrated to our meta-nilrt layer and independently maintained until such a time as we can deprecate it.

Thanks,

--
Alex Stewart
Software Engineer - NI Real-Time OS
NI (National Instruments)

alex.stewart@...