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 <[email protected]> PGP: 0x420902729A92C964 - https://denix.org/0x420902729A92C964 Fingerprint: 25FC E4A5 8A72 2F69 1186 6D76 4209 0272 9A92 C964 _______________________________________________ meta-arago mailing list [email protected] http://arago-project.org/cgi-bin/mailman/listinfo/meta-arago
