On 19/05/2021 18.05, Neal Gompa wrote:

On Wed, May 19, 2021 at 11:56 AM Peter Georg peter.georg@physik.uni-regensburg.de wrote:

...

Dear all,

I'd like to propose a SIG for CentOS Stream. Please see the proposal below.

Note: In case anyone has a better suggestion for a name, please let me know. I'm really terrible at naming things. And sorry in advance for any spelling or grammar mistakes (I'm not a native english speaker).

For everyone following the previously posted "RFC: Stream Kernel SIG Proposal": The goal of the "kmods" SIG proposed here has previously been proposed to be added to a potential "Stream Kernel SIG" as a fifth goal. However it seems to make sense to split the various different goals into seperate SIGs.

Disclaimer: I used the Hyperscale SIG description (https://wiki.centos.org/SpecialInterestGroup/Hyperscale) as a template. I hope that's OK.

That's totally fine!

...

Proposal: = kmods SIG =

== Goals == The kmods SIG will focus on providing kernel modules currently not available in CentOS Stream.

== Status == Proposed: RFC and looking for a sponsoring Governing Board member

== What's in scope == This SIG is a good place for any kernel module that is beneficial to CentOS Stream, but cannot be directly contributed to any of the involved upstream projects. These kernel modules may be divided in three categories:

=== Restore support for deprecated devices === The CentOS Stream kernel includes several kernel modules for which the list of supported devices has been limited by Red Hat. This SIG aims to provide versions of these kernel modules with restored support for as many deprecated and removed devices as possible.

A close collaboration with the kernel-plus developers is desired for these kernel modules.

=== In-kernel modules not enabled for CentOS Stream === Many in-kernel modules are simply disabled for the CentOS Stream kernel. This may either be due to drivers being deprecated and removed compared to older CentOS major releases or never being enabled in the first place. This SIG aims to provide these in-kernel drivers as external kernel modules to enable CentOS Stream running on a broader range of available hardware and provide other beneficial functionality.

A close collaboration with the kernel-plus developers is desired for these kernel modules. In addition it is desired to work with upstream to get any valuable kernel modules directly into the CentOS Stream kernel.

=== Third-party external kernel modules === This SIG also aims to provide third-party kernel modules for CentOS Stream not (yet) available in upstream kernel.

== What's not in scope == Anything that can be contributed directly to any of the involved upstream projects is not in scope. This includes, but is not limited to:

• New user space packages: These should be submitted to Fedora/EPEL
• Support for new architectures currently not supported by CentOS Stream
• Third-party kernel modules with non compatible license

I don't think that it makes sense to ship the user-space packages in EPEL if the kernel functionality isn't present in RHEL. This was something that we went over in Hyperscale with btrfs-progs, and my argument has basically been "people expect EPEL stuff to just work out of the box on RHEL, and we can't offer that with btrfs-progs in EPEL", so now Hyperscale maintains btrfs-progs in CBS. I suspect the same tack will make sense for this too.

I cannot contradict your argument. The example I thought about when I wrote this is wireguard: The kernel module is not available in RHEL 7 and 8, but wireguard-tools is in EPEL-7 and -8. Not sure about the EPEL policies in this case. At the end we'll probably have to deal with it on a case-by-case basis. Let me think about a better wording, or whether it is better to simply drop that one point.

...

== Roadmap ==

• Provide packages for in-kernel modules with restored support for

deprecated devices

• Provide packages for in-kernel modules that have been supported in

older CentOS major releases

• Provide packages for further beneficial kernel modules requested by

the community

== Resources == TBD

== Communication == The SIG uses the [[https://lists.centos.org/mailman/listinfo/centos-devel%7Ccentos-devel]] mailing list for coordination and communication.

TBD: Add note about regular meetings once established.

== Membership == The current set of members is:

##begin-members

• ...

##end-members

The SIG is co-chaired by ... and ....

Everybody is welcome to join and contribute to the SIG. Membership can be requested by asking on the [[https://lists.centos.org/mailman/listinfo/centos-devel%7Ccentos-devel]] mailing list. Any current member can raise objections and request a simple majority vote on membership applications. SIG members are expected to actively contribute or otherwise remain engaged with the project. Stale members may be removed by a simple majority vote after six months of inactivity.

The SIG is co-chaired by two equal chairpersons elected by SIG members for one year. Each chairperson is elected individually using a plurality vote.

It might make sense to see if we can bring ELRepo into the fold. A requirement for that would be the ability to build with RHEL in the buildroot, though. Perhaps we can get an arrangement for CBS to have RHEL buildroots like EPEL has?

There is obviously a large overlap with ELRepo. Phil Perry has been involved in previous discussions about this matter. And I think that he and others know that I'm in no way trying to compete with ELRepo, but instead trying to bring some of the great features ELRepo provides for RHEL (and its clones) to CentOS Stream. So despite not really answering your question, I just wanted to note that I'll be happy to work with ELRepo (and the kernel-plus maintainers).

I also wanted to note that the question about CBS having RHEL buildroots might also be interesting for other SIGs: Before CentOS Stream every SIG has been building for CentOS Linux, allowing the SIG repos to be consumed by RHEL users as well. Now with all SIGs moving from CentOS Linux to CentOS Stream this is not the case anymore. Are there any SIGs that plan to target both CentOS Stream and RHEL (or one of its clones)?

Hi,

chiming in too

On Thu, May 20, 2021 at 03:22:16PM +0000, Patrick Riehecky wrote:

Adding notes in line below:

On Wed, 2021-05-19 at 17:56 +0200, Peter Georg wrote:

<...>

...

Proposal: = kmods SIG =

== Goals == The kmods SIG will focus on providing kernel modules currently not available in CentOS Stream.

== Status == Proposed: RFC and looking for a sponsoring Governing Board member

As a board member I hereby indicate a willingness to sponsor. If another board member is passionate about this, I'll be happy to hand it over to them. I've regularly made use of external kmods (for old hardware and proprietary hardware)and would strongly like to see them continue in Stream!

+1

Emphasizing the possible issues: Since we won't have garanteed stable kernel ABI, so weak-updates may not always work, so that would imply building (all) kmod for each kernel release. Also that would mean extra care when the kmod version for a given driver is upgraded along with a newer kernel is installed. If that can be achieved, elrepo kmod will benefit from this work, done in Stream.

Best effort should be emphasized, volonteered work, thing may break etc... Make sure users expectation VS reality is covered. <...>

...

• Third-party kernel modules with non compatible license

Echoing other thoughts, packages in EPEL should be installable by folks with or without the SIG. So I'd suggest anything that isn't dependent on the kmods, should go into EPEL, but things that are kmod specific should probably stay within the SIG. In theory, if userspace is tied to the kmod, synchronizing updates would be cleaner if things were in just the one place.

I'm a bit concerned that "non compatible license" is a bit vague. Would this exclude DRBD, ZFS on Linux, OpenAFS, or nVidia? The nVidia bits seem to be 'yes, it is excluded', I'm less sure on the other two.

Not sure how useful is stream in the HPC world without nvidia drivers. Zfsonlinux is already taken care by them, afaik.

...

== Roadmap ==   * Provide packages for in-kernel modules with restored support for deprecated devices   * Provide packages for in-kernel modules that have been supported in older CentOS major releases   * Provide packages for further beneficial kernel modules requested by the community

I'd add to the roadmap, establish a strong dialog with our friends at ELRepo. In a perfect world we can get all the Stream kmods and RHEL kmods built under one process so folks don't need to duplicate effort .... in practice..... the shorter lifecycle of stream is a bit of an adventure here.

+1

If there are people willing to do it, +1 for this SIG. I am just a little worried by the possible amount of effort needed.

Tru

On 20/05/2021 19:26, Peter Georg wrote:

On 20/05/2021 18.27, Tru Huynh wrote:

...

Hi,

chiming in too

On Thu, May 20, 2021 at 03:22:16PM +0000, Patrick Riehecky wrote:

...

Adding notes in line below:

On Wed, 2021-05-19 at 17:56 +0200, Peter Georg wrote:

<...>

...

...

Proposal: = kmods SIG =

== Goals == The kmods SIG will focus on providing kernel modules currently not available in CentOS Stream.

== Status == Proposed: RFC and looking for a sponsoring Governing Board member

As a board member I hereby indicate a willingness to sponsor.  If another board member is passionate about this, I'll be happy to hand it over to them.  I've regularly made use of external kmods (for old hardware and proprietary hardware)and would strongly like to see them continue in Stream!

+1

Emphasizing the possible issues: Since we won't have garanteed stable kernel ABI, so weak-updates may not always work, so that would imply building (all) kmod for each kernel release. Also that would mean extra care when the kmod version for a given driver is upgraded along with a newer kernel is installed. If that can be achieved, elrepo kmod will benefit from this work, done in Stream.

Best effort should be emphasized, volonteered work, thing may break etc... Make sure users expectation VS reality is covered.

This issue has been discussed previously on this list. From experience reported by Phil Perry with CentOS Stream kernel updates, weak-updates are not an option. So yes, all kmods have to be rebuilt for each kernel release.

At which point I would seriously question the validity of using kmods. A DKMS-type solution (akmod?) would be more appropriate/beneficial IMHO.

That said, if you are intending to update packages for each kernel release, building them as well becomes less of an issue. From where will you pull your source code? For example, elrepo pulls updated sources from the RHEL kernel source code at every point release for drivers/devices that RH has disabled. So if you are updating the driver source from the matching Stream kernel source code and patching to reenable disabled drivers (plus fixing any new build issues), the package will need a version bump and rebuild for every kernel release anyway which negates much of the advantages of a dkms-type solution. Because of weak-updates, ELRepo only needs to do this once every 6 months for RHEL point releases, but you will likely be doing it for every Stream kernel release. Given the frequency of releases as Stream ramps up, you'll want to automate as much of this process as you can.

This is one of the reasons elrepo is not able to support Stream (massively increased workflow), and I think this is one of the major challenges you will need to overcome. Because you have access to the kernel in Stream (or a kernel-plus type offering), I would seriously consider tying to maintain as much of this as you can in-kernel rather than as out-of-tree modules. kmods/akmods are great when you have no alternative, but it's always preferable to do this stuff in-kernel where you can.

On 20/05/2021 21:43, Peter Georg wrote:

On 20/05/2021 21.55, Phil Perry wrote:

...

On 20/05/2021 19:26, Peter Georg wrote:

...

On 20/05/2021 18.27, Tru Huynh wrote:

...

Hi,

chiming in too

On Thu, May 20, 2021 at 03:22:16PM +0000, Patrick Riehecky wrote:

...

Adding notes in line below:

On Wed, 2021-05-19 at 17:56 +0200, Peter Georg wrote:

<...>

...

...

Proposal: = kmods SIG =

== Goals == The kmods SIG will focus on providing kernel modules currently not available in CentOS Stream.

== Status == Proposed: RFC and looking for a sponsoring Governing Board member

As a board member I hereby indicate a willingness to sponsor.  If another board member is passionate about this, I'll be happy to hand it over to them.  I've regularly made use of external kmods (for old hardware and proprietary hardware)and would strongly like to see them continue in Stream!

+1

Emphasizing the possible issues: Since we won't have garanteed stable kernel ABI, so weak-updates may not always work, so that would imply building (all) kmod for each kernel release. Also that would mean extra care when the kmod version for a given driver is upgraded along with a newer kernel is installed. If that can be achieved, elrepo kmod will benefit from this work, done in Stream.

Best effort should be emphasized, volonteered work, thing may break etc... Make sure users expectation VS reality is covered.

This issue has been discussed previously on this list. From experience reported by Phil Perry with CentOS Stream kernel updates, weak-updates are not an option. So yes, all kmods have to be rebuilt for each kernel release.

At which point I would seriously question the validity of using kmods. A DKMS-type solution (akmod?) would be more appropriate/beneficial IMHO.

That said, if you are intending to update packages for each kernel release, building them as well becomes less of an issue. From where will you pull your source code? For example, elrepo pulls updated sources from the RHEL kernel source code at every point release for drivers/devices that RH has disabled. So if you are updating the driver source from the matching Stream kernel source code and patching to reenable disabled drivers (plus fixing any new build issues), the package will need a version bump and rebuild for every kernel release anyway which negates much of the advantages of a dkms-type solution. Because of weak-updates, ELRepo only needs to do this once every 6 months for RHEL point releases, but you will likely be doing it for every Stream kernel release. Given the frequency of releases as Stream ramps up, you'll want to automate as much of this process as you can.

Just to make sure we are on the same page: We are talking about in-kernel modules here that are not enabled in RHEL or have some devices/adapters removed (i.e. the first two groups described in the proposal).

Yes.

Yes, the idea is to always use the updated kernel source code and apply patches on top. This is what I have already done for some packages ~3 months ago. So far I only had to update the patches for one module. For all other modules the update could be scripted. However the frequency of CentOS Stream 8 kernel releases has not been that high lately.

It's been a similar story here. So far, the only package I've needed to fix for 8.4 has been arcmsr for the simplification of scsi_partsize() backported from kernel-5.7, and the patch to revert removed devices needed updating for megaraid_sas where Red Hat restored some (but not all) of the devices they'd previously removed.

Judging by the number of internal releases the RHEL kernel goes through between point releases (-240 to -305 for 8.3 to 8.4), that equates to a couple kernel releases per week, on average. I'm guessing that once the Stream development process is happening fully in the open, that is the number of kernel releases we can expect in Stream.

IMHO for rebuilding kernel modules with deprecated adapters this is the only really safe option you have anyway (apart from the kernel-plus approach): The current ELRepo approach of pulling source code once for every minor release might run into issues in case these sources being updated in a later kernel update to this particular minor release. It is unlikely to happen, even more unlikely to cause any real issues, but possible.

Agreed. It does happen from time to time but it's pretty rare (as Red Hat does all it's development work/backporting in the previously unreleased "Stream" branch for RHEL-next once a point release is made). All we are seeing in the RHEL kernel is bug/security fixes within any given point release cycle hence the kernel ABI is amazingly stable within that point release cycle.

...

This is one of the reasons elrepo is not able to support Stream (massively increased workflow), and I think this is one of the major challenges you will need to overcome. Because you have access to the kernel in Stream (or a kernel-plus type offering), I would seriously consider tying to maintain as much of this as you can in-kernel rather than as out-of-tree modules. kmods/akmods are great when you have no alternative, but it's always preferable to do this stuff in-kernel where you can.

I agree. That's also why I added in the proposal that it is desired to work with upstream to directly get anything possible into CentOS Stream kernel. However, we all know that this is not feasible for all modules. IMHO this is especially not an option for modules of the first group (deprecated adapters). Although some people suggested to try to revert the removal of deprecated adapters in the CentOS Stream kernel, I do not see this happening. Afterall it is still Red Hat deciding what's going into the CentOS Stream kernel.

...

kernel-plus is of course an option, especially to re-enable support for

deprecated adapters. However there are use cases where you simply can not replace the kernel with kernel-plus (or have to use some otherwise patched kernel). In these cases the only feasible option (IMHO) is to use external kernel modules. But there is obviously a large overlap (especially for the first and second group of modules) between kernel-plus and this proposed SIG. Hence I hope both efforts can work closely together.

Sounds good.

On 20/05/2021 17.22, Patrick Riehecky wrote:

Adding notes in line below:

On Wed, 2021-05-19 at 17:56 +0200, Peter Georg wrote:

...

Dear all,

I'd like to propose a SIG for CentOS Stream. Please see the proposal below.

Note: In case anyone has a better suggestion for a name, please let me know. I'm really terrible at naming things. And sorry in advance for any spelling or grammar mistakes (I'm not a native english speaker).

For everyone following the previously posted "RFC: Stream Kernel SIG Proposal": The goal of the "kmods" SIG proposed here has previously been proposed to be added to a potential "Stream Kernel SIG" as a fifth goal. However it seems to make sense to split the various different goals into seperate SIGs.

Disclaimer: I used the Hyperscale SIG description ( https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.centos.org_Special...  ) as a template. I hope that's OK.

The more we can reuse things that work and make a cleaner/better/easier process the happier we will all be :)

...

Best,

Peter

Proposal: = kmods SIG =

== Goals == The kmods SIG will focus on providing kernel modules currently not available in CentOS Stream.

== Status == Proposed: RFC and looking for a sponsoring Governing Board member

As a board member I hereby indicate a willingness to sponsor. If another board member is passionate about this, I'll be happy to hand it over to them. I've regularly made use of external kmods (for old hardware and proprietary hardware)and would strongly like to see them continue in Stream!

...

== What's in scope == This SIG is a good place for any kernel module that is beneficial to CentOS Stream, but cannot be directly contributed to any of the involved upstream projects. These kernel modules may be divided in three categories:

=== Restore support for deprecated devices === The CentOS Stream kernel includes several kernel modules for which the list of supported devices has been limited by Red Hat. This SIG aims to many deprecated and removed devices as possible.

A close collaboration with the kernel-plus developers is desired for these kernel modules.

=== In-kernel modules not enabled for CentOS Stream === Many in-kernel modules are simply disabled for the CentOS Stream kernel. This may either be due to  drivers being deprecated and removed compared to older CentOS major releases or never being enabled in the first place. This SIG aims to provide these in-kernel drivers as external kernel modules to enable CentOS Stream running on a broader range of available hardware and provide other beneficial functionality.

A close collaboration with the kernel-plus developers is desired for these kernel modules. In addition it is desired to work with upstream to get any valuable kernel modules directly into the CentOS Stream kernel.

=== Third-party external kernel modules === This SIG also aims to provide third-party kernel modules for CentOS Stream not (yet) available in upstream kernel.

== What's not in scope == Anything that can be contributed directly to any of the involved upstream projects is not in scope. This includes, but is not limited to:

• New user space packages: These should be submitted to Fedora/EPEL
• Support for new architectures currently not supported by CentOS

Stream

• Third-party kernel modules with non compatible license

Echoing other thoughts, packages in EPEL should be installable by folks with or without the SIG. So I'd suggest anything that isn't dependent on the kmods, should go into EPEL, but things that are kmod specific should probably stay within the SIG. In theory, if userspace is tied to the kmod, synchronizing updates would be cleaner if things were in just the one place.

Makes sense. I'll wait for further input on this point and will then try to come up with a better solution.

I'm a bit concerned that "non compatible license" is a bit vague. Would this exclude DRBD, ZFS on Linux, OpenAFS, or nVidia? The nVidia bits seem to be 'yes, it is excluded', I'm less sure on the other two.

Concerning your examples: Afaik the CDDL (ZFS) is considered a free software license by the FSF. So I assume this should be fine. The nVidia bits are probably not allowed.

I think in the Wiki it is somewhere written that everything must be compatible with a "FOSS license". I can use the same wording here, despite not knowing in detail what qualifies a license as "FOSS".

But I'm not a lawyer, so in case there is someone with better knowledge about such licensing issues: Your help is highly appreciated!

...

== Roadmap ==   * Provide packages for in-kernel modules with restored support for deprecated devices   * Provide packages for in-kernel modules that have been supported in older CentOS major releases   * Provide packages for further beneficial kernel modules requested by the community

I'd add to the roadmap, establish a strong dialog with our friends at ELRepo. In a perfect world we can get all the Stream kmods and RHEL kmods built under one process so folks don't need to duplicate effort .... in practice..... the shorter lifecycle of stream is a bit of an adventure here.

I'll add it to the roadmap.

...

== Resources == TBD

From a security/assurance standpoint, the modules will need to be signed by a cert dedicated to this SIG stored on some sort of "hard token". Probably one cert per "release" (Stream 8, Stream 9, EL8?, EL9?) so they age out over time.

I can add signing of the modules here (or to the roadmap?). However it is not 100% clear to me yet how this should be done. Hence my idea was to first get started without signing any modules and try to get involved in the process the Hyperscale SIG is currently going through trying to figure out how to sign a kernel built by a SIG. I assume/hope a similar approach can then be used to sign these modules.

...

== Communication == The SIG uses the [[ https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.centos.org_mailma...  ]] mailing list for coordination and communication.

TBD: Add note about regular meetings once established.

== Membership == The current set of members is:

##begin-members   * ... ##end-members

The SIG is co-chaired by ... and ....

Everybody is welcome to join and contribute to the SIG. Membership can be requested by asking on the [[ https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.centos.org_mailma...  ]] mailing list. Any current member can raise objections and request a simple majority vote on membership applications. SIG members are expected to actively contribute or otherwise remain engaged with the six months of inactivity.

The SIG is co-chaired by two equal chairpersons elected by SIG members for one year. Each chairperson is elected individually using a plurality vote. _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.centos.org_mailma...

---

CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel

On 20/05/2021 20.11, Neal Gompa wrote:

On Thu, May 20, 2021 at 2:08 PM Peter Georg peter.georg@physik.uni-regensburg.de wrote:

...

On 20/05/2021 17.22, Patrick Riehecky wrote:

...

Adding notes in line below:

On Wed, 2021-05-19 at 17:56 +0200, Peter Georg wrote:

...

Dear all,

I'd like to propose a SIG for CentOS Stream. Please see the proposal below.

Note: In case anyone has a better suggestion for a name, please let me know. I'm really terrible at naming things. And sorry in advance for any spelling or grammar mistakes (I'm not a native english speaker).

For everyone following the previously posted "RFC: Stream Kernel SIG Proposal": The goal of the "kmods" SIG proposed here has previously been proposed to be added to a potential "Stream Kernel SIG" as a fifth goal. However it seems to make sense to split the various different goals into seperate SIGs.

Disclaimer: I used the Hyperscale SIG description ( https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.centos.org_Special... ) as a template. I hope that's OK.

The more we can reuse things that work and make a cleaner/better/easier process the happier we will all be :)

...

Best,

Peter

Proposal: = kmods SIG =

== Goals == The kmods SIG will focus on providing kernel modules currently not available in CentOS Stream.

== Status == Proposed: RFC and looking for a sponsoring Governing Board member

As a board member I hereby indicate a willingness to sponsor. If another board member is passionate about this, I'll be happy to hand it over to them. I've regularly made use of external kmods (for old hardware and proprietary hardware)and would strongly like to see them continue in Stream!

...

== What's in scope == This SIG is a good place for any kernel module that is beneficial to CentOS Stream, but cannot be directly contributed to any of the involved upstream projects. These kernel modules may be divided in three categories:

=== Restore support for deprecated devices === The CentOS Stream kernel includes several kernel modules for which the list of supported devices has been limited by Red Hat. This SIG aims to many deprecated and removed devices as possible.

A close collaboration with the kernel-plus developers is desired for these kernel modules.

=== In-kernel modules not enabled for CentOS Stream === Many in-kernel modules are simply disabled for the CentOS Stream kernel. This may either be due to drivers being deprecated and removed compared to older CentOS major releases or never being enabled in the first place. This SIG aims to provide these in-kernel drivers as external kernel modules to enable CentOS Stream running on a broader range of available hardware and provide other beneficial functionality.

A close collaboration with the kernel-plus developers is desired for these kernel modules. In addition it is desired to work with upstream to get any valuable kernel modules directly into the CentOS Stream kernel.

=== Third-party external kernel modules === This SIG also aims to provide third-party kernel modules for CentOS Stream not (yet) available in upstream kernel.

== What's not in scope == Anything that can be contributed directly to any of the involved upstream projects is not in scope. This includes, but is not limited to:

• New user space packages: These should be submitted to Fedora/EPEL
• Support for new architectures currently not supported by CentOS

Stream

• Third-party kernel modules with non compatible license

Echoing other thoughts, packages in EPEL should be installable by folks with or without the SIG. So I'd suggest anything that isn't dependent on the kmods, should go into EPEL, but things that are kmod specific should probably stay within the SIG. In theory, if userspace is tied to the kmod, synchronizing updates would be cleaner if things were in just the one place.

Makes sense. I'll wait for further input on this point and will then try to come up with a better solution.

...

I'm a bit concerned that "non compatible license" is a bit vague. Would this exclude DRBD, ZFS on Linux, OpenAFS, or nVidia? The nVidia bits seem to be 'yes, it is excluded', I'm less sure on the other two.

Concerning your examples: Afaik the CDDL (ZFS) is considered a free software license by the FSF. So I assume this should be fine. The nVidia bits are probably not allowed.

OpenZFS has not been allowed per Red Hat Legal, so I don't think you can do that.

Well, as I said: I'm not a lawyer :) But good to know, thanks!

Does this mean that legally the same restrictions that apply to getting a package into RHEL also apply to packages provided by a CentOS SIG?

Nvidia is more obviously not allowed as proprietary software.

Hi,

On 5/20/21 8:33 PM, Neal Gompa wrote:

...

...

...

...

I'm a bit concerned that "non compatible license" is a bit vague. Would this exclude DRBD, ZFS on Linux, OpenAFS, or nVidia? The nVidia bits seem to be 'yes, it is excluded', I'm less sure on the other two.

Concerning your examples: Afaik the CDDL (ZFS) is considered a free software license by the FSF. So I assume this should be fine. The nVidia bits are probably not allowed.

OpenZFS has not been allowed per Red Hat Legal, so I don't think you can do that.

Well, as I said: I'm not a lawyer :) But good to know, thanks!

Does this mean that legally the same restrictions that apply to getting a package into RHEL also apply to packages provided by a CentOS SIG?

Yes.

Do you know if OpenAFS would also be excluded from this SIG? We currently build the kmods ourselves for each kernel release but we would love to be able to push that upstream.

Cheers, Alex

On 21/05/2021 13.01, Neal Gompa wrote:

On Fri, May 21, 2021 at 6:36 AM Alex Iribarren alex.m.lists3@gmail.com wrote:

...

Hi,

On 5/20/21 8:33 PM, Neal Gompa wrote:

...

...

...

...

> I'm a bit concerned that "non compatible license" is a bit vague. > Would this exclude DRBD, ZFS on Linux, OpenAFS, or nVidia? The nVidia > bits seem to be 'yes, it is excluded', I'm less sure on the other two.

Concerning your examples: Afaik the CDDL (ZFS) is considered a free software license by the FSF. So I assume this should be fine. The nVidia bits are probably not allowed.

OpenZFS has not been allowed per Red Hat Legal, so I don't think you can do that.

Well, as I said: I'm not a lawyer :) But good to know, thanks!

Does this mean that legally the same restrictions that apply to getting a package into RHEL also apply to packages provided by a CentOS SIG?

Yes.

Do you know if OpenAFS would also be excluded from this SIG? We currently build the kmods ourselves for each kernel release but we would love to be able to push that upstream.

Unfortunately, yes. https://www.gnu.org/licenses/license-list.html#IBMPL

According to your link I assume you want to imply that only GPL (v2) compatible licenses are allowed?

I also looked up what Fedora considers a "good" license for packaging: https://fedoraproject.org/wiki/Licensing:Main?rd=Licensing#Good_Licenses

These two lists are quite different.

Not trying to imply that you are wrong, just trying to figure out what I should write in the proposal.

Can someone maybe contact legal to have an "official" answer what license requirements we have to adhere to for packaging within a CentOS SIG? Or is "GPL v2 compatible" the official answer?

Once we have an answer, it'd be good to add this to the CentOS Wiki. Currently there is only vague information there about licensing concerning packaging. Or at least I couldn't find it there.

Though at least that one seems to have hope to be replaced with one built into Linux in the near future: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/fs/af...

-- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel

On Friday, May 21, 2021 8:00 AM, Neal Gompa ngompa13@gmail.com wrote:

The Linux kernel is licensed GPLv2, so all kernel modules need to be compatible with that license.

If only things were that simple.

The linux kernel actually specifies that it's SPDX-License-Identifier is GPL-2.0 WITH Linux-syscall-note

It continues on to explain this exception to the GPL in the license rules for other licenses documentation. This includes a MODULE_LICENSE() tag for modules to gain or be restricted from EXPORT_SYMBOL_GPL().

As far as I can tell, OpenAFS honors the license tag system of the kernel and avoids calling kernel symbols that requires being GPL compatible. As such, it is compatible with the Linux kernel GPLv2 exception/syscall-note.

At the same time, IBM PL is on Fedora's list of recognized free software licenses.

So, I think it should be valid for the kmods SIG to expect to be able to include OpenAFS.

The situation still is far from ideal. The module should get the kernel marked as tainted. It would be nice if the largest contributor of code to OpenAFS (some company called "IBM/Red Hat") could work towards relicensing under the GPLv2. But the poor selection of license applied to OpenAFS shouldn't force exclusion.

On Saturday, May 22, 2021 8:31 PM, Neal Gompa ngompa13@gmail.com wrote:

On Sat, May 22, 2021 at 5:51 PM redbaronbrowser via CentOS-devel centos-devel@centos.org wrote:

...

On Friday, May 21, 2021 8:00 AM, Neal Gompa ngompa13@gmail.com wrote:

...

The Linux kernel is licensed GPLv2, so all kernel modules need to be compatible with that license.

If only things were that simple. The linux kernel actually specifies that it's SPDX-License-Identifier is GPL-2.0 WITH Linux-syscall-note It continues on to explain this exception to the GPL in the license rules for other licenses documentation. This includes a MODULE_LICENSE() tag for modules to gain or be restricted from EXPORT_SYMBOL_GPL(). As far as I can tell, OpenAFS honors the license tag system of the kernel and avoids calling kernel symbols that requires being GPL compatible. As such, it is compatible with the Linux kernel GPLv2 exception/syscall-note.

Your understanding is fundamentally wrong. The Linux-syscall-note explicitly does not cover the kernel interface, which is what kernel modules use.

I'm not discussing this further, though. I'm just going to say that Red Hat Legal has consistently told Fedora this over the years, and I do not expect this to change for CentOS.

My understanding is taken from the Linux Developer's mailing list.

I agree with you that if IBM/Red Hat Legal department has already ruled on this then we shouldn't be including IBM PL covered kernel modules. However, it would also be nice to have the exact wording from the IBM/RH Legal department.

This seems like a next level example of irony when the IBM/RH Legal department says that a IBM/RH sponsor project can't package/distribute a IBM/RH FOSS project because of the license that IBM/RH choose.

At some point it would be nice if OpenAFS project which is made up mostly of code owned by IBM/RH could acknowledge the issues that IBM/RH Legal department raises and address them so that CentOS, a IBM/RH sponsor project, can distirbute the kernel module someday in the future.

On Sunday, May 23, 2021 6:14 AM, Neal Gompa ngompa13@gmail.com wrote:

On Sun, May 23, 2021 at 6:44 AM redbaronbrowser redbaronbrowser@protonmail.com wrote:

...

My understanding is taken from the Linux Developer's mailing list. I agree with you that if IBM/Red Hat Legal department has already ruled on this then we shouldn't be including IBM PL covered kernel modules. However, it would also be nice to have the exact wording from the IBM/RH Legal department. This seems like a next level example of irony when the IBM/RH Legal department says that a IBM/RH sponsor project can't package/distribute a IBM/RH FOSS project because of the license that IBM/RH choose. At some point it would be nice if OpenAFS project which is made up mostly of code owned by IBM/RH could acknowledge the issues that IBM/RH Legal department raises and address them so that CentOS, a IBM/RH sponsor project, can distirbute the kernel module someday in the future.

You seem to be under the impression that IBM actually isdoing anything with Red Hat on this. They're not. Red Hat and IBM have separate legal departments entirely. Also, since OpenAFS has had contributions from folks other than IBM, it's not straightforward to relicense the project anymore.

I'm under the impression that IBM has been for a while saying they want to hear what they could do to help the needs of the FOSS community. To be fair to IBM, on some thing they have done a good job at listening.

I'm also under the impression that IBM indicated when buying Red Hat that they were continuing their investiment in helping the FOSS community.

Also, I see a major selling of Stream to be control is being handed over to the community. As Rich Bowen has pointed out, we are now responsible for the success (or failure) of Stream and if it gets us the results we want.

I don't expect a transistion to happen over night. If RH Legal continues to indicate there is good reasons why OpenAFS kernel modules can not be distributed in a CentOS SIG at the beginning of 2022, I can be understanding about that.

But there should be a path way forward for OpenAFS inclusion in the SIG someday if IBM and Red Hat are to be taken at their word. And it should be our obligation as a community to clearly state what our needs from those open ended offers are.

The birth of Stream should mean the community can expect to see "you can't expect that from CentOS" less often because for the majority of things the community should be defining what CentOS Stream is.

If IBM/RH Legal has said "you can't" in the past, that is fine. I don't hold it against them for doing their job. But moving forward when the obstacle is as close a partner as IBM, the answer from legal eventually needs to be "you can't right now, but let me get back to you on when you can."

Otherwise, it seems to me that the community is just being put through the downsides of this transition to Stream without enough advantages. If the "you can not"s remain exactly the same going from CentOS 8 to Stream 8, what is the point?

On Sunday, May 23, 2021 7:31 AM, Neal Gompa ngompa13@gmail.com wrote:

You are conflating completely different things.

First, IBM isn't involved in anything around CentOS Stream. Red Hat has been very consistent about this. Many Red Hatters have confirmed this over and over. If they were lying, they would be in considerable trouble for making such statements publicly.

I never said they are lying. It has been stated by Red Hat employees on this mailing list that Red Hat now has a special partnership with IBM. That should include having the contacts to speak on behalf of the CentOS project.

Second, IBM hasn't owned the OpenAFS project for many years. It was spun off in 2013 to the OpenAFS Foundation[1]. Additionally, the OpenAFS Foundation would need to gather approvals from the OpenAFS contributors themselves to relicense the code, since there's no CLA requirement to contribute. You are barking up the wrong tree to change the license of OpenAFS.

IBM hasn't been involved in the governance for many years. That is different than assigning copyright control. If you look at the top of each OpenAFS source file, you can see IBM still asserts copyright and is the copyright owner.

You are correct that there has been no CLA, that each contributor would have to be contacted or their code rewritten. That is going to be a huge undertaking. But going through that process should start with the largest copyright holder which remains IBM.

Third, Red Hat operates as a separate company under the IBM conglomerate. That means completely separate HR, legal, sales, marketing, and engineering teams. IBM also famously requires companies under its ownership to coordinate with each other as if they weren't owned by IBM, so Red Hat and IBM Cloud teams have to directly negotiate for deals with no help from the parent anyway.

I over simplified and I can understand why you would be frustrated with me. RH should still have a close enough relationship with IBM at this point to provide better help than just "legal says NO."

I'm not asking RH to assist in getting Oracle to relicense ZFS. I perfectly understand they don't have friendly relationship with Oracle. I wouldn't consider it fair to expect RH to assist with that. It is not my intention to ever push for OpenZFS inclusion.

However, in this specific instance for this specific kernel module, I think it is fair to say RH has a friendly relationship with IBM.

I'm personally getting very tired of how you keep doing this on the list. You don't disclose anything about yourself and you continue to attempt (and in some instances, succeed) at gaslighting the CentOS community. You're stoking the flames and I'm increasingly suspicious that you're trying to make this fail. I would appreciate it if you started operating in good faith rather than whatever you're doing now.

My understanding of "gaslighting" is promoting something the author knows to be false.

My key concern has been the openness gap for the Stream 8 kernel. If it was up to me then my focus right now would be kpatch and testing applying increments starting from the CentOS 8.3 release 240 of the kernel.

However, here is the commit history on gitlab for the Stream 8 kernel:

https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-8/-/commits...

It is *one* commit. There is no history of incremental changes.

So, was I "gaslighting" when I raised the concern that there is still an openness gap with Stream 8 and the Stream 8 kernel? Was I saying something I knew to be false?

Is gitlab presenting a series of individual commits for the Stream 8 kernel and proves I have presented a false concern?

I respect your feedback and your contributions. I am willing to accept that I have worded things poorly and need to reconsider how I word things in the future. But if you want to mischaracterize what I have said as "gaslighting" then there is nothing I can think of to do about that.

I'm also not sure what I can do about your claim that I am trying and in some cases had success in making Stream 8 fail. That is the exact opposite of what I want. I'm not astroturfing through other forums and have been instead presenting all my concerns specifically to this mailing list. If my reasoning is flawed then this audience should be the most qualified to know that. Any attacks through external forums on Stream that speak to a wider and less knowledgable audience is not performed by me.

If all it takes is one person pointing out flaws on the developer mailing list to cause failures then there is something else foundationally wrong. And again, causing failure is not my intention. I assume someone actually seeking to cause Stream 8 to fail would do a much better "job" at it.

This e-mail is very much off-topic for this list. However, the "kmods SIG Proposal" thread included a number of statements or assertions that I felt should be clarified.

On 5/23/2021 8:31 AM, ngompa13 at gmail.com (Neal Gompa) wrote:

On Sun, May 23, 2021 at 8:08 AM redbaronbrowser <redbaronbrowser at protonmail.com> wrote:

...

On Sunday, May 23, 2021 6:14 AM, Neal Gompa <ngompa13 at gmail.com> wrote:

...

On Sun, May 23, 2021 at 6:44 AM redbaronbrowser redbaronbrowser at protonmail.com wrote:

...

This seems like a next level example of irony when the IBM/RH Legal department says that a IBM/RH sponsor project can't package/distribute a IBM/RH FOSS project because of the license that IBM/RH choose. At some point it would be nice if OpenAFS project which is made up mostly of code owned by IBM/RH could acknowledge the issues that IBM/RH Legal department raises and address them so that CentOS, a IBM/RH sponsor project, can distirbute the kernel module someday in the future.

The IBM OpenAFS 1.0 release was posted to the IBM DeveloperWorks web site on 31 October 2000. This release was a fork of the commercial IBM AFS 3.6 product which continued to be developed and supported for more than a decade after the publishing of OpenAFS 1.0. IBM OpenAFS 1.0 was the first and only release from IBM. It consisted of a tarball and a LICENSE file containing the text of the IBM Public License 1.0 license.

The OpenAFS Project (www.openafs.org) was formed in the days that followed as an unincorporated association with participation from CMU, MIT, UMich, IBM, Intel and Morgan Stanley. The initial commit to the CVS repository (since converted to Git) was

commit 87c10e8d7f05dbbdf12ee9e8651dcec07e08af3f (tag: openafs-root, tag: openafs-ibm-1_0) Author: IBM <IBM> Date: Sat Nov 4 02:13:13 2000 +0000 Initial IBM OpenAFS 1.0 tree

3456 files changed, 968066 insertions(+)

The IBM Copyright and License information were added to each source file in

commit fb5bcd00fc6f1560d7d02115a0b5beaa3014a0e7 Author: Daria Phoebe Brashear shadow@dementia.org Date: Sat Nov 4 10:01:08 2000 +0000 Standardize License information

2058 files changed, 15605 insertions(+), 5719 deletions(-)

The tip of the current development branch is 72223e0958c2d7cddd968970547dd73fc3cc135.

git diff -w --stat fb5bcd00fc6f1560d..72223e0958c2d reports

5447 files changed, 1062235 insertions(+), 319453 deletions(-)

Commits are attributed to 254 unique email addresses; some of which belong to the same entity. Attributing these identities to lines of code via git blame results in the following top ten contributors across the entire repository.

36% 495583 IBM 19% 263820 Jeffrey Altman 9% 116742 Daria Phoebe Brashear 4% 54518 Chas Williams 3% 42678 Peter Scott 3% 40844 Simon Wilkinson 3% 39423 Russ Allbery 2% 32698 Andrew Deason 2% 32420 Asanka Herath 2% 29272 Dave Tanner

IBM is still the largest contributor but it has not been a majority for many years. IBM is attributed at a lower percentage when only the files required for the Linux kernel module are examined.

By the time I joined The OpenAFS Project (2003) the challenges of OpenAFS being both out-of-tree and GPL-incompatible were well understood by the community. Conversations with IBM regarding re-licensing of IBM OpenAFS 1.0 began in 2005 and continue to this day.

...

...

You seem to be under the impression that IBM actually is doing anything with Red Hat on this. They're not. Red Hat and IBM have separate legal departments entirely. Also, since OpenAFS has had contributions from folks other than IBM, it's not straightforward to relicense the project anymore.

A re-license by IBM of the original IBM DeveloperWorks release is a necessary step in any effort to re-license OpenAFS. There are more than 13500 commits from non-IBM entities; approximately 3700 impact the Linux kernel module. Not all of those commits are visible in the current development tip. Re-licensing is not out of the question but it is important to recognize the limits of what re-licensing can achieve.

After all contributors grant permission, the Linux kernel developers must be convinced to accept a dual-GPL/IPL10 license as a GPL compatible license. Assuming the change is accepted, the OpenAFS kernel module can make of GPL_ONLY functionality. That is a huge win. However, it will not result in OpenAFS being accepted into the Linux kernel. There are and will continue to be objections to its monolithic architecture combining filesystem, networking, and crypto all in one module. In addition to objections over pioctls, pags, its cross-platform code base, etc.

In addition, there is already an actively maintained implementation of AFS functionality in the Linux mainline kernel. The clean room development of the in-tree AFS and AF_RXRPC implementation began in 2001 and was actively supported by The OpenAFS Project up until my departure in 2012. This functionality has been shipped as part of Fedora since 31, is included in Ubuntu 20.10, and will be included in Debian 11 "bullseye".

...

I don't expect a transistion to happen over night. If RH Legal continues to indicate there is good reasons why OpenAFS kernel modules can not be distributed in a CentOS SIG at the beginning of 2022, I can be understanding about that.

But there should be a path way forward for OpenAFS inclusion in the SIG someday if IBM and Red Hat are to be taken at their word. And it should be our obligation as a community to clearly state what our needs from those open ended offers are.

While I continue to support efforts to encourage IBM and the OpenAFS developer community to re-license OpenAFS, I continue to believe that most efforts should be focused on improving the in-tree AFS and AF_RXRPC implementations rather than OpenAFS. Only the in-tree implementation can provide universal out-of-the-box /afs global namespace access. Out-of-the-box /afs is necessary for supporting a variety of container deployment workflows that require a ubiquitous secure global namespace across multi-clouds.

AF_RXRPC independent of AFS also has the potential to be a lightweight secure alternative for IoT services.

Second, IBM hasn't owned the OpenAFS project for many years. It was spun off in 2013 to the OpenAFS Foundation[1].

The OpenAFS Project has been independent of IBM from its inception. The OpenAFS Foundation was founded in 2013 to provide a not-for-profit corporate entity to manage money and sign contr

On 5/22/2021 5:51 PM, redbaronbrowser at protonmail.com (redbaronbrowser) wrote:

It would be nice if the largest contributor of code to OpenAFS (some company called "IBM/Red Hat") could work towards relicensing under the GPLv2.

I am happy to report that IBM Legal has approved a request to re-license the original 31 October 2000 IBM DeveloperWorks OpenAFS 1.0 distribution under GPLv2. The announcement was made today by Todd deSantis of IBM's AFS Support organization in an e-mail to the OpenAFS Developer's mailing list.

https://lists.openafs.org/pipermail/openafs-devel/2021-June/020707.html

This announcement is the result of more than a decade of behind the scene efforts. Yet it is just the first step in the journey that the OpenAFS community must complete before a GPLv2 OpenAFS Linux kernel module can be distributed.

Sincerely,

Jeffrey Altman

On May 21, 2021, at 07:01, Neal Gompa ngompa13@gmail.com wrote:

Though at least that one seems to have hope to be replaced with one built into Linux in the near future: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/fs/af...

I’m looking at building openafs kmods for the storage SIG, it I am also testing kAFS.

I’ve actually got a c9s VM running with this commit to turn kAFS on:

https://gitlab.com/jsbillings/kernel/-/commit/7749d2a944ef0a005f9b86bd3b9f20...

I’d love to work on a method building in-kernel kmods out of the kernel package. I could also build a whole SIG-branded kernel but that seems like a huge waste of time.

— Jonathan Billings

On 5/23/2021 10:32 AM, Peter Georg (peter.georg@physik.uni-regensburg.de) wrote:

Thanks to everyone for the input so far. I updated the original proposal to reflect your input. In case I forgot something, please let me know.

This looks very good so far. One comment below:

=== In-kernel modules not enabled for CentOS Stream === Many in-kernel modules are simply disabled for the CentOS Stream kernel. This may either be due to  drivers being deprecated and removed compared to older CentOS major releases or never being enabled in the first place. This SIG aims to provide these in-kernel drivers as external kernel modules to enable CentOS Stream running on a broader range of available hardware and provide other beneficial functionality.

=== Third-party external kernel modules ===

Might I suggest "out-of-kernel modules" instead of "third-party external kernel modules".

This SIG also aims to provide third-party kernel modules for CentOS Stream not (yet) available in upstream kernel.

The "not (yet)" makes me wonder what the criteria for inclusion are. Is it a requirement that the module might be accepted into the upstream kernel if submitted? If this is the intent, I believe that would exclude two categories of modules. First, modules that provide functionality already provided by an actively maintained in-kernel module. Second, modules whose licenses are not listed in include/linux/license.h.

Later on the "What's not in scope" section says:

• Third-party kernel modules with a non GPL v2 compatible license

which is overly broad. Might I suggest:

[BEGIN] ==== Out-of-kernel modules =====

This SIG also aims to provide out-of-kernel modules for CentOS that might be accepted into the upstream kernel if submitted. This category excludes:

* modules whose primary functionality is already provided by an actively maintained in-kernel module.

* modules whose licenses are not included in include/linux/license.h (see license_is_gpl_compatible()). [END]

I hope this is helpful.

Jeffrey Altman

I'm loving the ideas/thoughts/etc here!

Perhaps, we could add a Roadmap item for non-GPLv2 stuff? Personally, there are just a few items that I'd love to have which are not GPLv2. I'd hate to block on sorting this out now, when I suspect there will be some more input/concerns/etc.

Pat

On Mon, 2021-05-24 at 22:10 +0200, Peter Georg wrote:

On 23/05/2021 21.00, Jeffrey E Altman wrote:

...

On 5/23/2021 10:32 AM, Peter Georg (peter.georg@physik.uni-regensburg.de) wrote:

...

Thanks to everyone for the input so far. I updated the original proposal to reflect your input. In case I forgot something, please let me know.

This looks very good so far.  One comment below:

...

=== In-kernel modules not enabled for CentOS Stream === Many in-kernel modules are simply disabled for the CentOS Stream kernel. This may either be due to  drivers being deprecated and removed compared to older CentOS major releases or never being enabled in the first place. This SIG aims to provide these in-kernel drivers as external kernel modules to enable CentOS Stream running on a broader range of available hardware and provide other beneficial functionality.

=== Third-party external kernel modules ===

Might I suggest "out-of-kernel modules" instead of "third-party external kernel modules".

modules". "out-of-tree kernel modules" is probably a better description than "thrid-party external kernel modules". Hence I'm thinking about doing a s/thrid-party external/out-of-tree/g. But then I probably should also s/in-kernel/in-tree kernel/g.

Opinions?

Dicussing details like this, I think we are on a good way :)

...

...

This SIG also aims to provide third-party kernel modules for CentOS Stream not (yet) available in upstream kernel.

The "not (yet)" makes me wonder what the criteria for inclusion are.  Is it a requirement that the module might be accepted into the upstream kernel if submitted?  If this is the intent, I believe that would exclude two categories of modules.  First, modules that provide functionality already provided by an actively maintained in-kernel module.  Second, modules whose licenses are not listed in include/linux/license.h.

think it has been. I currently don't see why we should restrict the SIG to modules that might be accepted into upstream kernel. The restriction to GPL v2 compatible licenses is there due to legal reasons. Is there any reason why we should restrict ourselves to kernel modules that might be accepted into upstream?

...

Later on the "What's not in scope" section says:

> * Third-party kernel modules with a non GPL v2 compatible license which is overly broad.  Might I suggest:

[BEGIN] ==== Out-of-kernel modules =====

might be accepted into the upstream kernel if submitted.  This category excludes:

* modules whose primary functionality is already provided by an     actively maintained in-kernel module.

This restriction might be problematic in some cases. E.g. if an existing probably want to provide this kernel module even though the existing in-kernel module has not yet been replaced in upstream (and especially not been backported). A somewhat recent example: exFAT.

...

* modules whose licenses are not included in include/linux/license.h     (see license_is_gpl_compatible()). [END]

I'd probably change this section only a litte bit to avoid confusion and add an explanation for the restriction to GPL v2 copatible:

[BEGIN] === Out-of-tree kernel modules === This SIG also aims to provide out-of-tree kernel modules for CentOS legal reasons. [END]

The "GPL v2" restriction is mentioned twice in the description then. However I think this might not be bad at all.

...

I hope this is helpful.

Jeffrey Altman

---

CentOS-devel mailing list CentOS-devel@centos.org https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.centos.org_mailma...

---

CentOS-devel mailing list CentOS-devel@centos.org https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.centos.org_mailma...

On Mon, 2021-05-24 at 23:24 +0200, Peter Georg wrote:

On 24/05/2021 22.32, Patrick Riehecky wrote:

...

I'm loving the ideas/thoughts/etc here!

Perhaps, we could add a Roadmap item for non-GPLv2 stuff?  Personally, there are just a few items that I'd love to have which are not GPLv2. I'd hate to block on sorting this out now, when I suspect there will be some more input/concerns/etc.

Pat

Just to clarify: non-GPLv2 stuff is part of the proposal. But even the the discussion with Neal Gompa).

These modules are indeed not mentioned explicitely on the roadmap, but are included in the third point "Provide packages for further beneficial point with improved wording or add an additional point to the Roadmap.

What are the non GPLv2 items you are interested in? All the non-GPLv2 stuff I'm interested in is sadly out due to the restriction to GPLv2 compatible licenses.

The two modules non-GPLv2 modules I'd probably get the most use out of are ZFS on Linux and the nVidia display module.

Pat

On 25/05/2021 15.29, Neal Gompa wrote:

On Tue, May 25, 2021 at 9:05 AM Patrick Riehecky riehecky@fnal.gov wrote:

...

On Mon, 2021-05-24 at 23:24 +0200, Peter Georg wrote:

...

On 24/05/2021 22.32, Patrick Riehecky wrote:

...

I'm loving the ideas/thoughts/etc here!

Perhaps, we could add a Roadmap item for non-GPLv2 stuff? Personally, there are just a few items that I'd love to have which are not GPLv2. I'd hate to block on sorting this out now, when I suspect there will be some more input/concerns/etc.

Pat

Just to clarify: non-GPLv2 stuff is part of the proposal. But even the the discussion with Neal Gompa).

These modules are indeed not mentioned explicitely on the roadmap, but are included in the third point "Provide packages for further beneficial point with improved wording or add an additional point to the Roadmap.

What are the non GPLv2 items you are interested in? All the non-GPLv2 stuff I'm interested in is sadly out due to the restriction to GPLv2 compatible licenses.

The two modules non-GPLv2 modules I'd probably get the most use out of are ZFS on Linux and the nVidia display module.

ZoL produces kmod packages themselves and continuously integrates against CentOS Stream already. NVIDIA is doing their own kmod builds for RHEL and derivatives too.

I do not know about ZoL, but nVidia is currently not providing any kmod builds for CentOS Stream, only RHEL.

Anyway, this does not really matter as both have a non GPL v2 compatible license. Assuming that the restriction to GPL v2 compatible licenses for kernel modules by Red Hat Legal applies to CentOS (and its SIGs), I'm not sure there is anything we, and especially I, can do in this case. The only thing I can think of is asking Brian Exelbierd (Red Hat Liaison) for confirmation that this restriction indeed applies. However I expect the answer to be "Yes".

On Fri, May 28, 2021 at 6:35 AM Peter Georg peter.georg@physik.uni-regensburg.de wrote:

On 24/05/2021 22.32, Patrick Riehecky wrote:

...

I'm loving the ideas/thoughts/etc here!

Perhaps, we could add a Roadmap item for non-GPLv2 stuff? Personally, there are just a few items that I'd love to have which are not GPLv2. I'd hate to block on sorting this out now, when I suspect there will be some more input/concerns/etc.

Pat

Coming back to this question / licensing issue as it seems to be the last open question concerning this SIG proposal and Rich asked me to have a final draft ready by June 2nd:

Currently I see two possible options:

1. Add a restriction for out-of-tree kernel modules "to out-of-tree

kernel modules with a GPL v2 compatible license". Assuming that this is the current official policy and it won't change in a foreseeable future.

2. Add a more vague statement about out-of-tree kernel modules, i.e.

something like "restricted to out-of-tree kernel modules with cetrain licenses due to legal constraints". This probably means that effectively the same restriction to "GPLv2 compatible" applies for now, but no modifications are required in case the official policy concerning kernel module licenses changes in the future.

Opinions?

Option 1 is pretty much the only one I would expect that you'll get endorsement from the Board on. I would expect that it would be problematic for them to approve something that they know could lead to that kind of problem, especially given how much license compliance matters to *this* audience in particular.

-- 真実はいつも一つ！/ Always, there's only one truth!

On 23/05/2021 16:32, Peter Georg wrote: <snip>

• Work with other SIGs and others involved to establish a common

work-flow to sign kernels and/or kernel modules provided by SIGs.

<snip>

As Davide already mentioned earlier, signing kernel with CentOS distro key and/or secureboot isn't something that is possible (and doubt it will ever be possible)

See https://pagure.io/centos-infra/issue/307

So in short : if SIGs don't expect to sign kernel with the centos distro key (https://www.centos.org/keys/#centos-project-keys-starting-from-centos-8) and also don't expect their built kernel/kernel modules to be signed with the centos key pair used for secureboot, that's something that can be done.

I prefer mentioning this here *before* people start a SIG and then would hit a wall, as nothing would have been discussed as Requirement/must-have vs "nice-to-have" :-)

On 24/05/2021 16.38, Patrick Riehecky wrote:

On Sun, 2021-05-23 at 16:32 +0200, Peter Georg wrote:

...

Thanks to everyone for the input so far. I updated the original proposal to reflect your input. In case I forgot something, please let me know.

Short summary of changes:

• Added information about kmod specific user space tools
• Specify concrete license requirements for third-party kernel

modules

• Added working on a solution for signing kernel modules to the

Roadmap

• Put more emphasis on collaboration with other existing efforts

I am happy to hear all your comments and suggestions!

The updated proposal: = kmods SIG =

== Goals == The kmods SIG will focus on providing kernel modules currently not available in CentOS Stream.

== Status == Proposed: RFC and looking for a sponsoring Governing Board member

As a board member, I'll sponsor this.

Your support is greatly appreciated. I'll update the status next time I post an update. Thanks!

...

== What's in scope == This SIG is a good place for any kernel module that is beneficial to CentOS Stream, but cannot be directly contributed to any of the involved upstream projects. These kernel modules may be divided in three categories:

=== Restore support for deprecated devices === The CentOS Stream kernel includes several kernel modules for which the list of supported devices has been limited by Red Hat. This SIG aims to provide versions of these kernel modules with restored support for as many deprecated and removed devices as possible.

=== In-kernel modules not enabled for CentOS Stream === Many in-kernel modules are simply disabled for the CentOS Stream kernel. This may either be due to  drivers being deprecated and removed compared to older CentOS major releases or never being enabled in the first place. This SIG aims to provide these in-kernel drivers as external kernel modules to enable CentOS Stream running on a broader range of available hardware and provide other beneficial functionality.

=== Third-party external kernel modules === This SIG also aims to provide third-party kernel modules for CentOS Stream not (yet) available in upstream kernel.

=== User space tools === User space tools required by or specific to kernel modules provided by this SIG, which are not suitable to be included in EPEL, shall be provided by this SIG as well.

== What's not in scope == Anything that can be contributed directly to any of the involved upstream projects is not in scope. This includes, but is not limited to:

• Unrelated user space packages: These should be submitted to

Fedora/EPEL

• Support for new architectures currently not supported by CentOS

Stream

• Third-party kernel modules with a non GPL v2 compatible license

== Collaboration == It is desired to work closely together with other groups working on similar tasks within the CentOS Stream community and the broader Enterprise Linux community. In particular this includes, but is not limited to:

=== kernel-plus === Especially for in-kernel modules (the first two groups identified above) it is desired to closely work together with the kernel-plus developers/maintainers.

=== CentOS Stream kernel === A close collaboration with upstream is desired to get any valuable kernel module directly into the CentOS Stream kernel.

=== ELRepo === There is a large overlap with ELRepo for many of the kernel modules to be provided by this SIG for CentOS Stream. Hence we hope to establish a good connection with the ELRepo community which shall be beneficial to both sides.

== Roadmap ==   * Provide packages for in-kernel modules with restored support for deprecated devices   * Provide packages for in-kernel modules that have been supported in older CentOS major releases   * Provide packages for further beneficial kernel modules requested by the community   * Work with other SIGs and others involved to establish a common work-flow to sign kernels and/or kernel modules provided by SIGs.

== Resources == TBD

== Communication == The SIG uses the [[ https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.centos.org_mailma...  ]] mailing list for coordination and communication.

TBD: Add note about regular meetings once established.

== Membership == The current set of members is:

##begin-members   * ... ##end-members

The SIG is co-chaired by ... and ....

Everybody is welcome to join and contribute to the SIG. Membership can be requested by asking on the [[ https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.centos.org_mailma...  ]] mailing list. Any current member can raise objections and request a simple majority vote on membership applications. SIG members are expected to actively contribute or otherwise remain engaged with the project. Stale members may be removed by a simple majority vote after six months of inactivity.

The SIG is co-chaired by two equal chairpersons elected by SIG members for one year. Each chairperson is elected individually using a plurality vote.

---

CentOS-devel mailing list CentOS-devel@centos.org https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.centos.org_mailma...

---

CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel

On 25/05/2021 14.46, Rich Bowen wrote:

On 5/19/21 11:56 AM, Peter Georg wrote:

...

I'd like to propose a SIG for CentOS Stream. Please see the proposal below.

Loving all of the discussion and refinement here.

Note: The next board meeting is on June 9th. We request that you have a final draft of the proposal ready and in the wiki by June 2nd, so that the board has time to review.

The final draft is almost ready, hence this shall not be an issue.

However I do have some questions about the process (trying to follow https://wiki.centos.org/SIGGuide#The_SIG_Process as close as possible):

- It seems that the proposal currently does not meet the 7th requirement ("One member of the SIG should be a member of the Governing Board/Devteam"). Can this member be the same as the sponsoring Gonverning Board Member? Shall the sponsoring Governing Board Member typically be a member of the SIG?

- Who shall add the SIG proposal to the Wiki? According to the Wiki the sponsoring board member adds the SIG to the list of proposed SIGs. However, there is no information about who shall create the SIG description page. Shall I ask Patrick Riehecky as the sponsoring Governing Board member to post the final draft there or shall I request access to post the final draft myself (following https://wiki.centos.org/Contribute#Contribute_to_the_Wiki)?

- Am I missing any other requirements to get this proposal approved?

Peter

---

CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel

On 25/05/2021 14.46, Rich Bowen wrote:

On 5/19/21 11:56 AM, Peter Georg wrote:

...

I'd like to propose a SIG for CentOS Stream. Please see the proposal below.

Loving all of the discussion and refinement here.

Note: The next board meeting is on June 9th. We request that you have a final draft of the proposal ready and in the wiki by June 2nd, so that the board has time to review.

The final draft is now available at https://wiki.centos.org/SpecialInterestGroup/Kmods

Peter

---

CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel

Hello,

I'd like to participate in the kmod SIG.

I am interested in getting the in-kernel AFS client available to CentOS systems. This involves the kafs and rxrpc kernel modules. These kernel modules are already in-tree. I'd probably be targeting 9-stream, since it has the most mature version of the kAFS client in it.

Also, there needs to be a kafs-client non-kernel package, which makes the /afs mount available using the kernel module. kafs-client is already built in Fedora[1] so it's not a stretch to get it working in CentOS. The 9-stream filesystem package already supports the /afs mountpoint[2].

I'm also interested in participating in whatever the SIG decides for signing kmods.

1. https://src.fedoraproject.org/rpms/kafs-client 2. https://gitlab.com/redhat/centos-stream/rpms/filesystem/-/blob/c9s/filesyste...

On Wed, Jun 02, 2021 at 03:30:04PM +0200, Peter Georg wrote:

This looks like a really good example of what can be done within the scope of the proposed kmods SIG.

I'm already building test c9s kernels using this commit: https://gitlab.com/jsbillings/kernel/-/commit/eca86bdce910a83ff3b438c67e19f6...

I'd love to see how people are building the modules as separate packages rather than a whole new kernel (which takes a bit of time and CPU resources).

On 02/06/2021 16.00, Jonathan Billings wrote:

On Wed, Jun 02, 2021 at 03:30:04PM +0200, Peter Georg wrote:

...

This looks like a really good example of what can be done within the scope of the proposed kmods SIG.

I'm already building test c9s kernels using this commit: https://gitlab.com/jsbillings/kernel/-/commit/eca86bdce910a83ff3b438c67e19f6...

I'd love to see how people are building the modules as separate packages rather than a whole new kernel (which takes a bit of time and CPU resources).

There are different approaches how to do this. Currently I use the following approach to compile in-tree kernel modules disabled in EL:

* Get the kernel sources

* Modify the Makefile of the driver I'm interested in to enable it. This mainly means adding configs/compile flags as desired.

* Apply any required patches/backports to the driver I'm interested in. Backports are required as Red Hat's backports to the kernel often break drivers they are not interested in. (Note for future: As the Centos Stream 9 kernel is developed openly on GitLab, we might try to get these backports directly into the kernel sources and not apply patches for every pacakge build.)

* Directly invoke the driver's Makefile, e.g. make -C /usr/src/kernels/4.18.0-301.1.el8.x86_64 M=$PWD modules

I do all of that in a spec file similar to the Guidelines for KernelModules used by RPM Fusion [1].

Once the SIG has been approved I suggest to add a simple driver for each group of kernel modules. Once we are happy with these, we can use them as templates for similar modules. My suggestion for the first kernel modules is: - megaraid_sas and/or mlx4 for a kernel module with deprecated devices - isci for an in-tree kernel module not enabled in EL - wireguard for an out-of-tree kernel module (EL8 only)

From a packaging point of view the afs kernel module will look very similar to the isci kernel module.

[1]: https://rpmfusion.org/Packaging/KernelModules/Kmods2