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 _______________________________________________ meta-arago mailing list meta-arago@arago-project.org http://arago-project.org/cgi-bin/mailman/listinfo/meta-arago
