[OE-core] The state of DKMS in the Yocto community

[OE-core] 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@ni.com

Re: [OE-core] The state of DKMS in the Yocto community

[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@sidebranch.com
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@ni.com> 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@ni.com
>
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#159558): https://lists.openembedded.org/g/openembedded-core/message/159558
> Mute This Topic: https://lists.openembedded.org/mt/87645999/1051774
> Group Owner: openembedded-core+owner@lists.openembedded.org
> Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [leon@sidebranch.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>

Re: [OE-core] The state of DKMS in the Yocto community

[Bruce Ashfield]

On Fri, Dec 10, 2021 at 3:58 PM Alex Stewart <alex.stewart@ni.com> 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@ni.com
>
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#159558): https://lists.openembedded.org/g/openembedded-core/message/159558
> Mute This Topic: https://lists.openembedded.org/mt/87645999/1050810
> Group Owner: openembedded-core+owner@lists.openembedded.org
> Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [bruce.ashfield@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>


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

Re: [OE-core] The state of DKMS in the Yocto community

[Alex Stewart]

On 12/11/21 09:24, Bruce Ashfield wrote:
> On Fri, Dec 10, 2021 at 3:58 PM Alex Stewart <alex.stewart@ni.com> 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@ni.com

Re: [OE-core] The state of DKMS in the Yocto community

[Bruce Ashfield]

On Mon, Dec 13, 2021 at 7:28 AM Alex Stewart <alex.stewart@ni.com> wrote:
>
> On 12/11/21 09:24, Bruce Ashfield wrote:
> > On Fri, Dec 10, 2021 at 3:58 PM Alex Stewart <alex.stewart@ni.com> 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@ni.com
>
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#159618): https://lists.openembedded.org/g/openembedded-core/message/159618
> Mute This Topic: https://lists.openembedded.org/mt/87645999/1050810
> Group Owner: openembedded-core+owner@lists.openembedded.org
> Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [bruce.ashfield@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>


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

Re: [OE-core] The state of DKMS in the Yocto community

[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

Re: [OE-core] The state of DKMS in the Yocto community

[Khem Raj]

On Mon, Dec 13, 2021 at 4:28 AM Alex Stewart <alex.stewart@ni.com> wrote:
>
> On 12/11/21 09:24, Bruce Ashfield wrote:
> > On Fri, Dec 10, 2021 at 3:58 PM Alex Stewart <alex.stewart@ni.com> 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@ni.com
>

Re: [OE-core] The state of DKMS in the Yocto community

[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@ni.com