Re: [PATCH dunfell] cryptodev: Move to 1.12 revision

[Denys Dmytriyenko <denis@denix.org>]

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