* [PATCH dunfell] cryptodev: Move to 1.12 revision @ 2021-03-04 6:52 Nishanth Menon 2021-03-04 18:48 ` Denys Dmytriyenko 0 siblings, 1 reply; 10+ messages in thread From: Nishanth Menon @ 2021-03-04 6:52 UTC (permalink / raw) To: meta-arago Cryptodev out of kernel module and suite has yet another set of challenge with broken API compatibility. However, the complete list of patches beteween dunfell's default 1.10 and current latest 1.12 revisions: e0c25e289d6b (tag: cryptodev-linux-1.12) Release version 1.12 55c6315058fc Fix build for Linux 5.11-rc1 2f5e08aebf92 Fix build for Linux 5.9-rc1 e8263d2d682b remove VLA usage from authenc.c dafa42cadc86 Fix for change in Kernel 4.4.168 f4d3653c8dcb Release version 1.11 9e765068582a Fix build for Linux 5.8-rc1 7e72f6758f2d enabled the support for TLS1.1 - AES128-SHA1 - AES256-SHA1 98b163a23f6b cryptlib.c: fix build on kernel v5.5+ a1e738aef624 tests: cipher-aead-srtp: Fix cao->dst alignment f971e0cd4a0e Fix module loading with Linux v5.0-rc5 We have the following choices 1) just cherry-pick minimum set of kernel patches relevant for kernel compatibility OR 2) switch to a newer version with richer set of fixups Attempting to switch to 1.12 version with minimal changes as a better option to get a wider swath of kernel compatibility. Signed-off-by: Nishanth Menon <nm@ti.com> --- DISCLAIMER: This is probably a dumb way of switching to 1.12.. open to suggestions. NOTE: a) master is already on 1.12 -> So, I am suggesting this only for dunfell at the moment: http://git.openembedded.org/openembedded-core/tree/meta/recipes-kernel/cryptodev?h=master b) gatesgarth is on 1.11 -> we wont get the fixes needed for newer kernel, so a variant of this will be needed.. http://git.openembedded.org/openembedded-core/tree/meta/recipes-kernel/cryptodev?h=gatesgarth c) dunfell is still on 1.10 -> Same story as gatesgarth.. http://git.openembedded.org/openembedded-core/tree/meta/recipes-kernel/cryptodev?h=dunfell .../recipes-kernel/cryptodev/cryptodev-linux_%.bbappend | 5 +++++ .../recipes-kernel/cryptodev/cryptodev-module_%.bbappend | 5 +++++ .../recipes-kernel/cryptodev/cryptodev-tests_%.bbappend | 6 ++++++ 3 files changed, 16 insertions(+) create mode 100644 meta-arago-distro/recipes-kernel/cryptodev/cryptodev-linux_%.bbappend create mode 100644 meta-arago-distro/recipes-kernel/cryptodev/cryptodev-tests_%.bbappend diff --git a/meta-arago-distro/recipes-kernel/cryptodev/cryptodev-linux_%.bbappend b/meta-arago-distro/recipes-kernel/cryptodev/cryptodev-linux_%.bbappend new file mode 100644 index 000000000000..a3fb634463fd --- /dev/null +++ b/meta-arago-distro/recipes-kernel/cryptodev/cryptodev-linux_%.bbappend @@ -0,0 +1,5 @@ +# Bring in fixes including https://github.com/cryptodev-linux/cryptodev-linux/pull/55 +# just pull 1.12 revision, everything else remains the same. +PR = "1.12" +PR_append = ".arago0" +SRCREV = "e0c25e289d6baf1d83c2b9cb523d3bc237d0c0c9" diff --git a/meta-arago-distro/recipes-kernel/cryptodev/cryptodev-module_%.bbappend b/meta-arago-distro/recipes-kernel/cryptodev/cryptodev-module_%.bbappend index f8a35cd73765..602ada0daf3a 100644 --- a/meta-arago-distro/recipes-kernel/cryptodev/cryptodev-module_%.bbappend +++ b/meta-arago-distro/recipes-kernel/cryptodev/cryptodev-module_%.bbappend @@ -1,3 +1,8 @@ +# Bring in fixes including https://github.com/cryptodev-linux/cryptodev-linux/pull/55 +# just pull 1.12 revision, everything else remains the same. + +PR = "1.12" PR_append = ".arago0" +SRCREV = "e0c25e289d6baf1d83c2b9cb523d3bc237d0c0c9" KERNEL_MODULE_AUTOLOAD += "cryptodev" diff --git a/meta-arago-distro/recipes-kernel/cryptodev/cryptodev-tests_%.bbappend b/meta-arago-distro/recipes-kernel/cryptodev/cryptodev-tests_%.bbappend new file mode 100644 index 000000000000..dee8f40862cb --- /dev/null +++ b/meta-arago-distro/recipes-kernel/cryptodev/cryptodev-tests_%.bbappend @@ -0,0 +1,6 @@ +# Bring in fixes including https://github.com/cryptodev-linux/cryptodev-linux/pull/55 +# just pull 1.12 revision, everything else remains the same. + +PR = "1.12" +PR_append = ".arago0" +SRCREV = "e0c25e289d6baf1d83c2b9cb523d3bc237d0c0c9" -- 2.25.1.377.g2d2118b814c1 ^ permalink raw reply related [flat|nested] 10+ messages in thread
* Re: [PATCH dunfell] cryptodev: Move to 1.12 revision 2021-03-04 6:52 [PATCH dunfell] cryptodev: Move to 1.12 revision Nishanth Menon @ 2021-03-04 18:48 ` Denys Dmytriyenko 2021-03-04 19:48 ` Denys Dmytriyenko 2021-03-04 23:18 ` Nishanth Menon 0 siblings, 2 replies; 10+ messages in thread From: Denys Dmytriyenko @ 2021-03-04 18:48 UTC (permalink / raw) To: Nishanth Menon; +Cc: meta-arago On Thu, Mar 04, 2021 at 12:52:00AM -0600, Nishanth Menon wrote: > Cryptodev out of kernel module and suite has yet another set of > challenge with broken API compatibility. However, the complete list of > patches beteween dunfell's default 1.10 and current latest 1.12 revisions: > e0c25e289d6b (tag: cryptodev-linux-1.12) Release version 1.12 > 55c6315058fc Fix build for Linux 5.11-rc1 > 2f5e08aebf92 Fix build for Linux 5.9-rc1 > e8263d2d682b remove VLA usage from authenc.c > dafa42cadc86 Fix for change in Kernel 4.4.168 > f4d3653c8dcb Release version 1.11 > 9e765068582a Fix build for Linux 5.8-rc1 > 7e72f6758f2d enabled the support for TLS1.1 - AES128-SHA1 - AES256-SHA1 > 98b163a23f6b cryptlib.c: fix build on kernel v5.5+ > a1e738aef624 tests: cipher-aead-srtp: Fix cao->dst alignment > f971e0cd4a0e Fix module loading with Linux v5.0-rc5 > > We have the following choices > 1) just cherry-pick minimum set of kernel patches relevant for kernel > compatibility > OR > 2) switch to a newer version with richer set of fixups > > Attempting to switch to 1.12 version with minimal changes as a better > option to get a wider swath of kernel compatibility. > > Signed-off-by: Nishanth Menon <nm@ti.com> > --- > > DISCLAIMER: This is probably a dumb way of switching to 1.12.. open to > suggestions. It is still probably the cleanest - just 2 vars in 3 bbappends. You might want to mention that you need this for 5.10 (or 5.9+) kernel upgrade. The issue is due to upgrading the kernel from one LTS to the next, while staying on the older Yocto LTS, which was 5.4-specific... BTW, I haven't yet reviewed your meta-ti patches, will do that next. > NOTE: > a) master is already on 1.12 -> So, I am suggesting this only for dunfell at the > moment: http://git.openembedded.org/openembedded-core/tree/meta/recipes-kernel/cryptodev?h=master > > b) gatesgarth is on 1.11 -> we wont get the fixes needed for newer > kernel, so a variant of this will be needed.. http://git.openembedded.org/openembedded-core/tree/meta/recipes-kernel/cryptodev?h=gatesgarth > > c) dunfell is still on 1.10 -> Same story as gatesgarth.. http://git.openembedded.org/openembedded-core/tree/meta/recipes-kernel/cryptodev?h=dunfell > > .../recipes-kernel/cryptodev/cryptodev-linux_%.bbappend | 5 +++++ > .../recipes-kernel/cryptodev/cryptodev-module_%.bbappend | 5 +++++ > .../recipes-kernel/cryptodev/cryptodev-tests_%.bbappend | 6 ++++++ > 3 files changed, 16 insertions(+) > create mode 100644 meta-arago-distro/recipes-kernel/cryptodev/cryptodev-linux_%.bbappend > create mode 100644 meta-arago-distro/recipes-kernel/cryptodev/cryptodev-tests_%.bbappend > > diff --git a/meta-arago-distro/recipes-kernel/cryptodev/cryptodev-linux_%.bbappend b/meta-arago-distro/recipes-kernel/cryptodev/cryptodev-linux_%.bbappend > new file mode 100644 > index 000000000000..a3fb634463fd > --- /dev/null > +++ b/meta-arago-distro/recipes-kernel/cryptodev/cryptodev-linux_%.bbappend > @@ -0,0 +1,5 @@ > +# Bring in fixes including https://github.com/cryptodev-linux/cryptodev-linux/pull/55 > +# just pull 1.12 revision, everything else remains the same. > +PR = "1.12" PV here. Stands for Package Version. And PR is for Package Revision (i.e. repackaging of the same version) > +PR_append = ".arago0" Not necessarily needed, if PV is set correctly _and_ SRCREV matches the one from OE-Core master for 1.12. > +SRCREV = "e0c25e289d6baf1d83c2b9cb523d3bc237d0c0c9" > diff --git a/meta-arago-distro/recipes-kernel/cryptodev/cryptodev-module_%.bbappend b/meta-arago-distro/recipes-kernel/cryptodev/cryptodev-module_%.bbappend > index f8a35cd73765..602ada0daf3a 100644 > --- a/meta-arago-distro/recipes-kernel/cryptodev/cryptodev-module_%.bbappend > +++ b/meta-arago-distro/recipes-kernel/cryptodev/cryptodev-module_%.bbappend > @@ -1,3 +1,8 @@ > +# Bring in fixes including https://github.com/cryptodev-linux/cryptodev-linux/pull/55 > +# just pull 1.12 revision, everything else remains the same. > + > +PR = "1.12" Same. > PR_append = ".arago0" This one was already there due to KERNEL_MODULE_AUTOLOAD below. > +SRCREV = "e0c25e289d6baf1d83c2b9cb523d3bc237d0c0c9" > > KERNEL_MODULE_AUTOLOAD += "cryptodev" > diff --git a/meta-arago-distro/recipes-kernel/cryptodev/cryptodev-tests_%.bbappend b/meta-arago-distro/recipes-kernel/cryptodev/cryptodev-tests_%.bbappend > new file mode 100644 > index 000000000000..dee8f40862cb > --- /dev/null > +++ b/meta-arago-distro/recipes-kernel/cryptodev/cryptodev-tests_%.bbappend > @@ -0,0 +1,6 @@ > +# Bring in fixes including https://github.com/cryptodev-linux/cryptodev-linux/pull/55 > +# just pull 1.12 revision, everything else remains the same. > + > +PR = "1.12" Same. > +PR_append = ".arago0" Same. > +SRCREV = "e0c25e289d6baf1d83c2b9cb523d3bc237d0c0c9" > -- > 2.25.1.377.g2d2118b814c1 > > _______________________________________________ > meta-arago mailing list > meta-arago@arago-project.org > http://arago-project.org/cgi-bin/mailman/listinfo/meta-arago > -- Regards, Denys Dmytriyenko <denis@denix.org> PGP: 0x420902729A92C964 - https://denix.org/0x420902729A92C964 Fingerprint: 25FC E4A5 8A72 2F69 1186 6D76 4209 0272 9A92 C964 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH dunfell] cryptodev: Move to 1.12 revision 2021-03-04 18:48 ` Denys Dmytriyenko @ 2021-03-04 19:48 ` Denys Dmytriyenko 2021-03-04 23:14 ` Nishanth Menon 2021-03-04 23:18 ` Nishanth Menon 1 sibling, 1 reply; 10+ messages in thread From: Denys Dmytriyenko @ 2021-03-04 19:48 UTC (permalink / raw) To: Nishanth Menon; +Cc: meta-arago BTW, you'd need to ensure updating cryptodev from 1.10 to 1.12 does not affect current 5.4-based builds and/or releases. I'm sure it will build fine against this older kernel (most of Makefile changes), but concerned about any run-time regressions (the actual code changes). On Thu, Mar 04, 2021 at 01:48:11PM -0500, Denys Dmytriyenko wrote: > On Thu, Mar 04, 2021 at 12:52:00AM -0600, Nishanth Menon wrote: > > Cryptodev out of kernel module and suite has yet another set of > > challenge with broken API compatibility. However, the complete list of > > patches beteween dunfell's default 1.10 and current latest 1.12 revisions: > > e0c25e289d6b (tag: cryptodev-linux-1.12) Release version 1.12 > > 55c6315058fc Fix build for Linux 5.11-rc1 > > 2f5e08aebf92 Fix build for Linux 5.9-rc1 > > e8263d2d682b remove VLA usage from authenc.c > > dafa42cadc86 Fix for change in Kernel 4.4.168 > > f4d3653c8dcb Release version 1.11 > > 9e765068582a Fix build for Linux 5.8-rc1 > > 7e72f6758f2d enabled the support for TLS1.1 - AES128-SHA1 - AES256-SHA1 > > 98b163a23f6b cryptlib.c: fix build on kernel v5.5+ > > a1e738aef624 tests: cipher-aead-srtp: Fix cao->dst alignment > > f971e0cd4a0e Fix module loading with Linux v5.0-rc5 > > > > We have the following choices > > 1) just cherry-pick minimum set of kernel patches relevant for kernel > > compatibility > > OR > > 2) switch to a newer version with richer set of fixups > > > > Attempting to switch to 1.12 version with minimal changes as a better > > option to get a wider swath of kernel compatibility. > > > > Signed-off-by: Nishanth Menon <nm@ti.com> > > --- > > > > DISCLAIMER: This is probably a dumb way of switching to 1.12.. open to > > suggestions. > > It is still probably the cleanest - just 2 vars in 3 bbappends. You might want > to mention that you need this for 5.10 (or 5.9+) kernel upgrade. > > The issue is due to upgrading the kernel from one LTS to the next, while > staying on the older Yocto LTS, which was 5.4-specific... BTW, I haven't yet > reviewed your meta-ti patches, will do that next. > > > > NOTE: > > a) master is already on 1.12 -> So, I am suggesting this only for dunfell at the > > moment: http://git.openembedded.org/openembedded-core/tree/meta/recipes-kernel/cryptodev?h=master > > > > b) gatesgarth is on 1.11 -> we wont get the fixes needed for newer > > kernel, so a variant of this will be needed.. http://git.openembedded.org/openembedded-core/tree/meta/recipes-kernel/cryptodev?h=gatesgarth > > > > c) dunfell is still on 1.10 -> Same story as gatesgarth.. http://git.openembedded.org/openembedded-core/tree/meta/recipes-kernel/cryptodev?h=dunfell > > > > .../recipes-kernel/cryptodev/cryptodev-linux_%.bbappend | 5 +++++ > > .../recipes-kernel/cryptodev/cryptodev-module_%.bbappend | 5 +++++ > > .../recipes-kernel/cryptodev/cryptodev-tests_%.bbappend | 6 ++++++ > > 3 files changed, 16 insertions(+) > > create mode 100644 meta-arago-distro/recipes-kernel/cryptodev/cryptodev-linux_%.bbappend > > create mode 100644 meta-arago-distro/recipes-kernel/cryptodev/cryptodev-tests_%.bbappend > > > > diff --git a/meta-arago-distro/recipes-kernel/cryptodev/cryptodev-linux_%.bbappend b/meta-arago-distro/recipes-kernel/cryptodev/cryptodev-linux_%.bbappend > > new file mode 100644 > > index 000000000000..a3fb634463fd > > --- /dev/null > > +++ b/meta-arago-distro/recipes-kernel/cryptodev/cryptodev-linux_%.bbappend > > @@ -0,0 +1,5 @@ > > +# Bring in fixes including https://github.com/cryptodev-linux/cryptodev-linux/pull/55 > > +# just pull 1.12 revision, everything else remains the same. > > +PR = "1.12" > > PV here. Stands for Package Version. And PR is for Package Revision (i.e. > repackaging of the same version) > > > > +PR_append = ".arago0" > > Not necessarily needed, if PV is set correctly _and_ SRCREV matches the one > from OE-Core master for 1.12. > > > > +SRCREV = "e0c25e289d6baf1d83c2b9cb523d3bc237d0c0c9" > > diff --git a/meta-arago-distro/recipes-kernel/cryptodev/cryptodev-module_%.bbappend b/meta-arago-distro/recipes-kernel/cryptodev/cryptodev-module_%.bbappend > > index f8a35cd73765..602ada0daf3a 100644 > > --- a/meta-arago-distro/recipes-kernel/cryptodev/cryptodev-module_%.bbappend > > +++ b/meta-arago-distro/recipes-kernel/cryptodev/cryptodev-module_%.bbappend > > @@ -1,3 +1,8 @@ > > +# Bring in fixes including https://github.com/cryptodev-linux/cryptodev-linux/pull/55 > > +# just pull 1.12 revision, everything else remains the same. > > + > > +PR = "1.12" > > Same. > > > > PR_append = ".arago0" > > This one was already there due to KERNEL_MODULE_AUTOLOAD below. > > > > +SRCREV = "e0c25e289d6baf1d83c2b9cb523d3bc237d0c0c9" > > > > KERNEL_MODULE_AUTOLOAD += "cryptodev" > > diff --git a/meta-arago-distro/recipes-kernel/cryptodev/cryptodev-tests_%.bbappend b/meta-arago-distro/recipes-kernel/cryptodev/cryptodev-tests_%.bbappend > > new file mode 100644 > > index 000000000000..dee8f40862cb > > --- /dev/null > > +++ b/meta-arago-distro/recipes-kernel/cryptodev/cryptodev-tests_%.bbappend > > @@ -0,0 +1,6 @@ > > +# Bring in fixes including https://github.com/cryptodev-linux/cryptodev-linux/pull/55 > > +# just pull 1.12 revision, everything else remains the same. > > + > > +PR = "1.12" > > Same. > > > > +PR_append = ".arago0" > > Same. > > > > +SRCREV = "e0c25e289d6baf1d83c2b9cb523d3bc237d0c0c9" > > -- > > 2.25.1.377.g2d2118b814c1 > > > > _______________________________________________ > > meta-arago mailing list > > meta-arago@arago-project.org > > http://arago-project.org/cgi-bin/mailman/listinfo/meta-arago > > > > -- > Regards, > Denys Dmytriyenko <denis@denix.org> > PGP: 0x420902729A92C964 - https://denix.org/0x420902729A92C964 > Fingerprint: 25FC E4A5 8A72 2F69 1186 6D76 4209 0272 9A92 C964 > _______________________________________________ > meta-arago mailing list > meta-arago@arago-project.org > http://arago-project.org/cgi-bin/mailman/listinfo/meta-arago > ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH dunfell] cryptodev: Move to 1.12 revision 2021-03-04 19:48 ` Denys Dmytriyenko @ 2021-03-04 23:14 ` Nishanth Menon 2021-03-05 0:58 ` Denys Dmytriyenko 0 siblings, 1 reply; 10+ messages in thread From: Nishanth Menon @ 2021-03-04 23:14 UTC (permalink / raw) To: Denys Dmytriyenko; +Cc: meta-arago On 14:48-20210304, Denys Dmytriyenko wrote: > BTW, you'd need to ensure updating cryptodev from 1.10 to 1.12 does not affect > current 5.4-based builds and/or releases. I'm sure it will build fine against > this older kernel (most of Makefile changes), but concerned about any run-time > regressions (the actual code changes). Thank you, actually you bring out a very good point here. While I know we can create our own internal private fork of arago for upstream component testing, I am starting to wonder if creating either of: a) meta-ti-mainline that builds on top of meta-ti OR b) meta-arago-mainline on top of meta-arago is a smarter approach - personally, I prefer (a)? While, I don't want to end up creating too many layers, but your point is valid that I should also be careful to not mess with folks using the meta-arago in production environments having to deal with challenges we are trying to flush out by testing the bleeding edge of kernel - and I'd like to make sure TI ecosystem is able to leverage/contribute as well (an internal fork will not be that useful).. Any thoughts? -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH dunfell] cryptodev: Move to 1.12 revision 2021-03-04 23:14 ` Nishanth Menon @ 2021-03-05 0:58 ` Denys Dmytriyenko 2021-03-05 1:24 ` Nishanth Menon 0 siblings, 1 reply; 10+ messages in thread From: Denys Dmytriyenko @ 2021-03-05 0:58 UTC (permalink / raw) To: Nishanth Menon; +Cc: meta-arago On Thu, Mar 04, 2021 at 05:14:34PM -0600, Nishanth Menon wrote: > On 14:48-20210304, Denys Dmytriyenko wrote: > > BTW, you'd need to ensure updating cryptodev from 1.10 to 1.12 does not affect > > current 5.4-based builds and/or releases. I'm sure it will build fine against > > this older kernel (most of Makefile changes), but concerned about any run-time > > regressions (the actual code changes). > > Thank you, actually you bring out a very good point here. While I know > we can create our own internal private fork of arago for upstream > component testing, I am starting to wonder if creating either of: > > a) meta-ti-mainline that builds on top of meta-ti > OR > b) meta-arago-mainline on top of meta-arago > > is a smarter approach - personally, I prefer (a)? While, I don't want > to end up creating too many layers, but your point is valid that I > should also be careful to not mess with folks using the meta-arago in > production environments having to deal with challenges we are trying > to flush out by testing the bleeding edge of kernel - and I'd like to > make sure TI ecosystem is able to leverage/contribute as well (an > internal fork will not be that useful).. First of all, an internal fork was an unintended consequence. But since we are discussing this in a public forum, I won't go into more details. :) Creating yet another layer is certainly an option. For mainline purposes (a) is definitely a better choice. And I assume that would be public... On the other hand, if you only need this for couple of recipes, you can do this with alternative providers. E.g. instead of altering existing recipes with bbappends (e.g. cryptodev), you can have many providers for the same package (e.g. linux-ti-staging, linux-ti-mainline, even linux-yocto from OE-core all provide the Linux kernel, or virtual/kernel; same with u-boot from OE-core and u-boot-ti-staging plus u-boot-ti-mainline provide U-boot bootloader, like virtual/bootloaader). Those can be switched with a global PREFERRED_PROVIDER_<pkg> variable: https://git.yoctoproject.org/cgit/cgit.cgi/meta-ti/tree/conf/machine/include/k3.inc#n13 In other words, if cryptodev is the only such case right now, it's less involved to create cryptodev-ti-mainline recipes, set those to corresponding PROVIDES, as well as PREFERRED_PROVIDER_ in necessary config files. Let me know if you need help with that. > Any thoughts? > > -- > Regards, > Nishanth Menon > Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D > -- Regards, Denys Dmytriyenko <denis@denix.org> PGP: 0x420902729A92C964 - https://denix.org/0x420902729A92C964 Fingerprint: 25FC E4A5 8A72 2F69 1186 6D76 4209 0272 9A92 C964 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH dunfell] cryptodev: Move to 1.12 revision 2021-03-05 0:58 ` Denys Dmytriyenko @ 2021-03-05 1:24 ` Nishanth Menon 2021-03-05 2:26 ` Denys Dmytriyenko 0 siblings, 1 reply; 10+ messages in thread From: Nishanth Menon @ 2021-03-05 1:24 UTC (permalink / raw) To: Denys Dmytriyenko; +Cc: meta-arago On 19:58-20210304, Denys Dmytriyenko wrote: > On Thu, Mar 04, 2021 at 05:14:34PM -0600, Nishanth Menon wrote: > > On 14:48-20210304, Denys Dmytriyenko wrote: > > > BTW, you'd need to ensure updating cryptodev from 1.10 to 1.12 does not affect > > > current 5.4-based builds and/or releases. I'm sure it will build fine against > > > this older kernel (most of Makefile changes), but concerned about any run-time > > > regressions (the actual code changes). > > > > Thank you, actually you bring out a very good point here. While I know > > we can create our own internal private fork of arago for upstream > > component testing, I am starting to wonder if creating either of: > > > > a) meta-ti-mainline that builds on top of meta-ti > > OR > > b) meta-arago-mainline on top of meta-arago > > > > is a smarter approach - personally, I prefer (a)? While, I don't want > > to end up creating too many layers, but your point is valid that I > > should also be careful to not mess with folks using the meta-arago in > > production environments having to deal with challenges we are trying > > to flush out by testing the bleeding edge of kernel - and I'd like to > > make sure TI ecosystem is able to leverage/contribute as well (an > > internal fork will not be that useful).. > > First of all, an internal fork was an unintended consequence. But since we are > discussing this in a public forum, I won't go into more details. :) :) understood :) > > Creating yet another layer is certainly an option. For mainline purposes (a) > is definitely a better choice. And I assume that would be public... yes, that is my thought. > > On the other hand, if you only need this for couple of recipes, you can do > this with alternative providers. E.g. instead of altering existing recipes > with bbappends (e.g. cryptodev), you can have many providers for the same > package (e.g. linux-ti-staging, linux-ti-mainline, even linux-yocto from > OE-core all provide the Linux kernel, or virtual/kernel; same with u-boot > from OE-core and u-boot-ti-staging plus u-boot-ti-mainline provide U-boot > bootloader, like virtual/bootloaader). Those can be switched with a global > PREFERRED_PROVIDER_<pkg> variable: > > https://git.yoctoproject.org/cgit/cgit.cgi/meta-ti/tree/conf/machine/include/k3.inc#n13 > > In other words, if cryptodev is the only such case right now, it's less > involved to create cryptodev-ti-mainline recipes, set those to corresponding > PROVIDES, as well as PREFERRED_PROVIDER_ in necessary config files. Let me > know if you need help with that. Hmm.. Thanks.. yeah, it is cryptodev today, something else tomorrow, in addition, I need to expand from purely kernel and u-boot upstream components alone to TF-A, linux-firmware upstream and eventually few additional packages etc. Mostly as a forward looking layer to uncover issues ahead of time. My thoughts on this is as follows: While the provider view can easily fit as well, it is a little less distracting or in some cases, un-intended usage to keep a "experimental" and "forward looking" layer away from users of production layer - then the distinction is very clearcut and risks(essentially "you are on your own") associated with the same would be clear as well. Who knows, some day, we might be even be able to delete such a layer since upstream will be rocksolid (touch wood).. -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH dunfell] cryptodev: Move to 1.12 revision 2021-03-05 1:24 ` Nishanth Menon @ 2021-03-05 2:26 ` Denys Dmytriyenko 2021-03-05 2:34 ` Nishanth Menon 0 siblings, 1 reply; 10+ messages in thread From: Denys Dmytriyenko @ 2021-03-05 2:26 UTC (permalink / raw) To: Nishanth Menon; +Cc: meta-arago On Thu, Mar 04, 2021 at 07:24:11PM -0600, Nishanth Menon wrote: > On 19:58-20210304, Denys Dmytriyenko wrote: > > On Thu, Mar 04, 2021 at 05:14:34PM -0600, Nishanth Menon wrote: > > > Thank you, actually you bring out a very good point here. While I know > > > we can create our own internal private fork of arago for upstream > > > component testing, I am starting to wonder if creating either of: > > > > > > a) meta-ti-mainline that builds on top of meta-ti > > > OR > > > b) meta-arago-mainline on top of meta-arago > > > > > > is a smarter approach - personally, I prefer (a)? While, I don't want > > > to end up creating too many layers, but your point is valid that I > > > should also be careful to not mess with folks using the meta-arago in > > > production environments having to deal with challenges we are trying > > > to flush out by testing the bleeding edge of kernel - and I'd like to > > > make sure TI ecosystem is able to leverage/contribute as well (an > > > internal fork will not be that useful).. > > > > First of all, an internal fork was an unintended consequence. But since we are > > discussing this in a public forum, I won't go into more details. :) > > :) understood :) > > > > > Creating yet another layer is certainly an option. For mainline purposes (a) > > is definitely a better choice. And I assume that would be public... > > yes, that is my thought. Good, anything BSP-specific is meta-ti, hence meta-ti-mainline. While meta-arago is for anything Apps or Distro-specific. It was also used as a dumping ground for anything un-upstreamable or with non-standard dependencies. As meta-ti used to depend on OE-Core only at first, now it's OE-Core plus meta-arm. So, if you have a component that depends on anything else, you can't have it in meta-ti or meta-ti-mainline layers. We can talk about Yocto Project compatibility requirements separately... > > On the other hand, if you only need this for couple of recipes, you can do > > this with alternative providers. E.g. instead of altering existing recipes > > with bbappends (e.g. cryptodev), you can have many providers for the same > > package (e.g. linux-ti-staging, linux-ti-mainline, even linux-yocto from > > OE-core all provide the Linux kernel, or virtual/kernel; same with u-boot > > from OE-core and u-boot-ti-staging plus u-boot-ti-mainline provide U-boot > > bootloader, like virtual/bootloaader). Those can be switched with a global > > PREFERRED_PROVIDER_<pkg> variable: > > > > https://git.yoctoproject.org/cgit/cgit.cgi/meta-ti/tree/conf/machine/include/k3.inc#n13 > > > > In other words, if cryptodev is the only such case right now, it's less > > involved to create cryptodev-ti-mainline recipes, set those to corresponding > > PROVIDES, as well as PREFERRED_PROVIDER_ in necessary config files. Let me > > know if you need help with that. > > > Hmm.. Thanks.. yeah, it is cryptodev today, something else tomorrow, > in addition, I need to expand from purely kernel and u-boot upstream > components alone to TF-A, linux-firmware upstream and eventually few > additional packages etc. Mostly as a forward looking layer to uncover > issues ahead of time. My thoughts on this is as follows: While the > provider view can easily fit as well, it is a little less distracting > or in some cases, un-intended usage to keep a "experimental" and > "forward looking" layer away from users of production layer - then the > distinction is very clearcut and risks(essentially "you are on your > own") associated with the same would be clear as well. Who knows, some > day, we might be even be able to delete such a layer since upstream will > be rocksolid (touch wood).. Ah, that would the most glorious day for sure! :) Anyway, if you intend to have cryptodev, atf/tf-a, optee, linux-firmware and such, then sure, a separate mainline-only layer would be the best. BTW, things like SGX and RGX will also fit there nicely. -- Regards, Denys Dmytriyenko <denis@denix.org> PGP: 0x420902729A92C964 - https://denix.org/0x420902729A92C964 Fingerprint: 25FC E4A5 8A72 2F69 1186 6D76 4209 0272 9A92 C964 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH dunfell] cryptodev: Move to 1.12 revision 2021-03-05 2:26 ` Denys Dmytriyenko @ 2021-03-05 2:34 ` Nishanth Menon 0 siblings, 0 replies; 10+ messages in thread From: Nishanth Menon @ 2021-03-05 2:34 UTC (permalink / raw) To: Denys Dmytriyenko; +Cc: meta-arago On 21:26-20210304, Denys Dmytriyenko wrote: > On Thu, Mar 04, 2021 at 07:24:11PM -0600, Nishanth Menon wrote: > > On 19:58-20210304, Denys Dmytriyenko wrote: > > > On Thu, Mar 04, 2021 at 05:14:34PM -0600, Nishanth Menon wrote: > > > > Thank you, actually you bring out a very good point here. While I know > > > > we can create our own internal private fork of arago for upstream > > > > component testing, I am starting to wonder if creating either of: > > > > > > > > a) meta-ti-mainline that builds on top of meta-ti > > > > OR > > > > b) meta-arago-mainline on top of meta-arago > > > > > > > > is a smarter approach - personally, I prefer (a)? While, I don't want > > > > to end up creating too many layers, but your point is valid that I > > > > should also be careful to not mess with folks using the meta-arago in > > > > production environments having to deal with challenges we are trying > > > > to flush out by testing the bleeding edge of kernel - and I'd like to > > > > make sure TI ecosystem is able to leverage/contribute as well (an > > > > internal fork will not be that useful).. > > > > > > First of all, an internal fork was an unintended consequence. But since we are > > > discussing this in a public forum, I won't go into more details. :) > > > > :) understood :) > > > > > > > > Creating yet another layer is certainly an option. For mainline purposes (a) > > > is definitely a better choice. And I assume that would be public... > > > > yes, that is my thought. > > Good, anything BSP-specific is meta-ti, hence meta-ti-mainline. > > While meta-arago is for anything Apps or Distro-specific. It was also used > as a dumping ground for anything un-upstreamable or with non-standard > dependencies. > > As meta-ti used to depend on OE-Core only at first, now it's OE-Core plus > meta-arm. So, if you have a component that depends on anything else, you can't > have it in meta-ti or meta-ti-mainline layers. We can talk about Yocto Project > compatibility requirements separately... Thank you for your guidance here. > > > > > On the other hand, if you only need this for couple of recipes, you can do > > > this with alternative providers. E.g. instead of altering existing recipes > > > with bbappends (e.g. cryptodev), you can have many providers for the same > > > package (e.g. linux-ti-staging, linux-ti-mainline, even linux-yocto from > > > OE-core all provide the Linux kernel, or virtual/kernel; same with u-boot > > > from OE-core and u-boot-ti-staging plus u-boot-ti-mainline provide U-boot > > > bootloader, like virtual/bootloaader). Those can be switched with a global > > > PREFERRED_PROVIDER_<pkg> variable: > > > > > > https://git.yoctoproject.org/cgit/cgit.cgi/meta-ti/tree/conf/machine/include/k3.inc#n13 > > > > > > In other words, if cryptodev is the only such case right now, it's less > > > involved to create cryptodev-ti-mainline recipes, set those to corresponding > > > PROVIDES, as well as PREFERRED_PROVIDER_ in necessary config files. Let me > > > know if you need help with that. > > > > > > Hmm.. Thanks.. yeah, it is cryptodev today, something else tomorrow, > > in addition, I need to expand from purely kernel and u-boot upstream > > components alone to TF-A, linux-firmware upstream and eventually few > > additional packages etc. Mostly as a forward looking layer to uncover > > issues ahead of time. My thoughts on this is as follows: While the > > provider view can easily fit as well, it is a little less distracting > > or in some cases, un-intended usage to keep a "experimental" and > > "forward looking" layer away from users of production layer - then the > > distinction is very clearcut and risks(essentially "you are on your > > own") associated with the same would be clear as well. Who knows, some > > day, we might be even be able to delete such a layer since upstream will > > be rocksolid (touch wood).. > > Ah, that would the most glorious day for sure! :) > > Anyway, if you intend to have cryptodev, atf/tf-a, optee, linux-firmware and > such, then sure, a separate mainline-only layer would be the best. BTW, things > like SGX and RGX will also fit there nicely. > Thanks for your feedback. I have to take it internally to get all the blessings I need to make things move forward.. -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH dunfell] cryptodev: Move to 1.12 revision 2021-03-04 18:48 ` Denys Dmytriyenko 2021-03-04 19:48 ` Denys Dmytriyenko @ 2021-03-04 23:18 ` Nishanth Menon 2021-03-05 0:27 ` Denys Dmytriyenko 1 sibling, 1 reply; 10+ messages in thread From: Nishanth Menon @ 2021-03-04 23:18 UTC (permalink / raw) To: Denys Dmytriyenko; +Cc: meta-arago On 13:48-20210304, Denys Dmytriyenko wrote: > On Thu, Mar 04, 2021 at 12:52:00AM -0600, Nishanth Menon wrote: > > Cryptodev out of kernel module and suite has yet another set of [...] > > +PR_append = ".arago0" > > Same. Thanks.. Subject to our thread continuing in parallel if a new layer is needed... just posting for reference a v2 - inline: -- >8 -- From 7a345806bda670973300e64e32affcf0ceab2d01 Mon Sep 17 00:00:00 2001 From: Nishanth Menon <nm@ti.com> Date: Thu, 4 Mar 2021 00:26:29 -0600 Subject: [PATCH V2 master/dunfell] cryptodev: Move to 1.12 revision Cryptodev out of kernel module and suite has yet another set of challenge with broken API compatibility. However, the complete list of patches beteween dunfell's default 1.10 and current latest 1.12 revisions: e0c25e289d6b (tag: cryptodev-linux-1.12) Release version 1.12 55c6315058fc Fix build for Linux 5.11-rc1 2f5e08aebf92 Fix build for Linux 5.9-rc1 e8263d2d682b remove VLA usage from authenc.c dafa42cadc86 Fix for change in Kernel 4.4.168 f4d3653c8dcb Release version 1.11 9e765068582a Fix build for Linux 5.8-rc1 7e72f6758f2d enabled the support for TLS1.1 - AES128-SHA1 - AES256-SHA1 98b163a23f6b cryptlib.c: fix build on kernel v5.5+ a1e738aef624 tests: cipher-aead-srtp: Fix cao->dst alignment f971e0cd4a0e Fix module loading with Linux v5.0-rc5 We have the following choices 1) just cherry-pick minimum set of kernel patches relevant for kernel compatibility OR 2) switch to a newer version with richer set of fixups Attempting to switch to 1.12 version with minimal changes as a better option to get a wider swath of kernel compatibility (v5.5 to v5.11), vs the default of v5.4 kernel in dunfell vanilla. Signed-off-by: Nishanth Menon <nm@ti.com> --- .../recipes-kernel/cryptodev/cryptodev-linux_%.bbappend | 5 +++++ .../recipes-kernel/cryptodev/cryptodev-module_%.bbappend | 5 +++++ .../recipes-kernel/cryptodev/cryptodev-tests_%.bbappend | 5 +++++ 3 files changed, 15 insertions(+) create mode 100644 meta-arago-distro/recipes-kernel/cryptodev/cryptodev-linux_%.bbappend create mode 100644 meta-arago-distro/recipes-kernel/cryptodev/cryptodev-tests_%.bbappend diff --git a/meta-arago-distro/recipes-kernel/cryptodev/cryptodev-linux_%.bbappend b/meta-arago-distro/recipes-kernel/cryptodev/cryptodev-linux_%.bbappend new file mode 100644 index 000000000000..a4ae187d4082 --- /dev/null +++ b/meta-arago-distro/recipes-kernel/cryptodev/cryptodev-linux_%.bbappend @@ -0,0 +1,5 @@ +# Bring in fixes including https://github.com/cryptodev-linux/cryptodev-linux/pull/55 +# just pull 1.12 revision, everything else remains the same. + +PV = "1.12" +SRCREV = "e0c25e289d6baf1d83c2b9cb523d3bc237d0c0c9" diff --git a/meta-arago-distro/recipes-kernel/cryptodev/cryptodev-module_%.bbappend b/meta-arago-distro/recipes-kernel/cryptodev/cryptodev-module_%.bbappend index f8a35cd73765..a1e1c91978c4 100644 --- a/meta-arago-distro/recipes-kernel/cryptodev/cryptodev-module_%.bbappend +++ b/meta-arago-distro/recipes-kernel/cryptodev/cryptodev-module_%.bbappend @@ -1,3 +1,8 @@ +# Bring in fixes including https://github.com/cryptodev-linux/cryptodev-linux/pull/55 +# just pull 1.12 revision, everything else remains the same. + +PV = "1.12" PR_append = ".arago0" +SRCREV = "e0c25e289d6baf1d83c2b9cb523d3bc237d0c0c9" KERNEL_MODULE_AUTOLOAD += "cryptodev" diff --git a/meta-arago-distro/recipes-kernel/cryptodev/cryptodev-tests_%.bbappend b/meta-arago-distro/recipes-kernel/cryptodev/cryptodev-tests_%.bbappend new file mode 100644 index 000000000000..a4ae187d4082 --- /dev/null +++ b/meta-arago-distro/recipes-kernel/cryptodev/cryptodev-tests_%.bbappend @@ -0,0 +1,5 @@ +# Bring in fixes including https://github.com/cryptodev-linux/cryptodev-linux/pull/55 +# just pull 1.12 revision, everything else remains the same. + +PV = "1.12" +SRCREV = "e0c25e289d6baf1d83c2b9cb523d3bc237d0c0c9" -- 2.25.1.377.g2d2118b814c1 -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D ^ permalink raw reply related [flat|nested] 10+ messages in thread
* Re: [PATCH dunfell] cryptodev: Move to 1.12 revision 2021-03-04 23:18 ` Nishanth Menon @ 2021-03-05 0:27 ` Denys Dmytriyenko 0 siblings, 0 replies; 10+ messages in thread From: Denys Dmytriyenko @ 2021-03-05 0:27 UTC (permalink / raw) To: Nishanth Menon; +Cc: meta-arago On Thu, Mar 04, 2021 at 05:18:45PM -0600, Nishanth Menon wrote: > On 13:48-20210304, Denys Dmytriyenko wrote: > > On Thu, Mar 04, 2021 at 12:52:00AM -0600, Nishanth Menon wrote: > > > Cryptodev out of kernel module and suite has yet another set of > > [...] > > > > +PR_append = ".arago0" > > > > Same. > > Thanks.. Subject to our thread continuing in parallel if a new layer is > needed... just posting for reference a v2 - inline: Overall looks fine - thanks for addressing all my comments. We'll see in the other thread if this is needed. > -- >8 -- > From 7a345806bda670973300e64e32affcf0ceab2d01 Mon Sep 17 00:00:00 2001 > From: Nishanth Menon <nm@ti.com> > Date: Thu, 4 Mar 2021 00:26:29 -0600 > Subject: [PATCH V2 master/dunfell] cryptodev: Move to 1.12 revision > > Cryptodev out of kernel module and suite has yet another set of > challenge with broken API compatibility. However, the complete list of > patches beteween dunfell's default 1.10 and current latest 1.12 revisions: > e0c25e289d6b (tag: cryptodev-linux-1.12) Release version 1.12 > 55c6315058fc Fix build for Linux 5.11-rc1 > 2f5e08aebf92 Fix build for Linux 5.9-rc1 > e8263d2d682b remove VLA usage from authenc.c > dafa42cadc86 Fix for change in Kernel 4.4.168 > f4d3653c8dcb Release version 1.11 > 9e765068582a Fix build for Linux 5.8-rc1 > 7e72f6758f2d enabled the support for TLS1.1 - AES128-SHA1 - AES256-SHA1 > 98b163a23f6b cryptlib.c: fix build on kernel v5.5+ > a1e738aef624 tests: cipher-aead-srtp: Fix cao->dst alignment > f971e0cd4a0e Fix module loading with Linux v5.0-rc5 > > We have the following choices > 1) just cherry-pick minimum set of kernel patches relevant for kernel > compatibility > OR > 2) switch to a newer version with richer set of fixups > > Attempting to switch to 1.12 version with minimal changes as a better > option to get a wider swath of kernel compatibility (v5.5 to v5.11), vs > the default of v5.4 kernel in dunfell vanilla. > > Signed-off-by: Nishanth Menon <nm@ti.com> > --- > .../recipes-kernel/cryptodev/cryptodev-linux_%.bbappend | 5 +++++ > .../recipes-kernel/cryptodev/cryptodev-module_%.bbappend | 5 +++++ > .../recipes-kernel/cryptodev/cryptodev-tests_%.bbappend | 5 +++++ > 3 files changed, 15 insertions(+) > create mode 100644 meta-arago-distro/recipes-kernel/cryptodev/cryptodev-linux_%.bbappend > create mode 100644 meta-arago-distro/recipes-kernel/cryptodev/cryptodev-tests_%.bbappend > > diff --git a/meta-arago-distro/recipes-kernel/cryptodev/cryptodev-linux_%.bbappend b/meta-arago-distro/recipes-kernel/cryptodev/cryptodev-linux_%.bbappend > new file mode 100644 > index 000000000000..a4ae187d4082 > --- /dev/null > +++ b/meta-arago-distro/recipes-kernel/cryptodev/cryptodev-linux_%.bbappend > @@ -0,0 +1,5 @@ > +# Bring in fixes including https://github.com/cryptodev-linux/cryptodev-linux/pull/55 > +# just pull 1.12 revision, everything else remains the same. > + > +PV = "1.12" > +SRCREV = "e0c25e289d6baf1d83c2b9cb523d3bc237d0c0c9" > diff --git a/meta-arago-distro/recipes-kernel/cryptodev/cryptodev-module_%.bbappend b/meta-arago-distro/recipes-kernel/cryptodev/cryptodev-module_%.bbappend > index f8a35cd73765..a1e1c91978c4 100644 > --- a/meta-arago-distro/recipes-kernel/cryptodev/cryptodev-module_%.bbappend > +++ b/meta-arago-distro/recipes-kernel/cryptodev/cryptodev-module_%.bbappend > @@ -1,3 +1,8 @@ > +# Bring in fixes including https://github.com/cryptodev-linux/cryptodev-linux/pull/55 > +# just pull 1.12 revision, everything else remains the same. > + > +PV = "1.12" > PR_append = ".arago0" > +SRCREV = "e0c25e289d6baf1d83c2b9cb523d3bc237d0c0c9" > > KERNEL_MODULE_AUTOLOAD += "cryptodev" > diff --git a/meta-arago-distro/recipes-kernel/cryptodev/cryptodev-tests_%.bbappend b/meta-arago-distro/recipes-kernel/cryptodev/cryptodev-tests_%.bbappend > new file mode 100644 > index 000000000000..a4ae187d4082 > --- /dev/null > +++ b/meta-arago-distro/recipes-kernel/cryptodev/cryptodev-tests_%.bbappend > @@ -0,0 +1,5 @@ > +# Bring in fixes including https://github.com/cryptodev-linux/cryptodev-linux/pull/55 > +# just pull 1.12 revision, everything else remains the same. > + > +PV = "1.12" > +SRCREV = "e0c25e289d6baf1d83c2b9cb523d3bc237d0c0c9" > -- > 2.25.1.377.g2d2118b814c1 > > -- > Regards, > Nishanth Menon > Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D > -- Regards, Denys Dmytriyenko <denis@denix.org> PGP: 0x420902729A92C964 - https://denix.org/0x420902729A92C964 Fingerprint: 25FC E4A5 8A72 2F69 1186 6D76 4209 0272 9A92 C964 ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2021-03-05 2:33 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-03-04 6:52 [PATCH dunfell] cryptodev: Move to 1.12 revision Nishanth Menon 2021-03-04 18:48 ` Denys Dmytriyenko 2021-03-04 19:48 ` Denys Dmytriyenko 2021-03-04 23:14 ` Nishanth Menon 2021-03-05 0:58 ` Denys Dmytriyenko 2021-03-05 1:24 ` Nishanth Menon 2021-03-05 2:26 ` Denys Dmytriyenko 2021-03-05 2:34 ` Nishanth Menon 2021-03-04 23:18 ` Nishanth Menon 2021-03-05 0:27 ` Denys Dmytriyenko
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.