On Oct 26, 2019, at 15:37, Adrian Bunk <[email protected]> wrote:
> On Sat, Oct 26, 2019 at 10:34:44AM -0400, Rich Persaud wrote:
>> ...
>> To avoid YP users assuming that YP and/or the upstream kernel has done
>> hardware testing for YP LTS, we may want to document specific testing
>> actions that are expected from YP LTS users. E.g. should YP downstreams
>> work directly with CKI via the Linux Foundation, to pool hardware test
>> results? Should they report hw test results to other YP LTS users?
>
> Aren't the testing actions expected from YP LTS users the same as for
> any other YP user?
>
> My understanding is that the hardware support provided by YP is just an
> example BSP mainly used by YP, and real-world project get their hardware
> support either from a 3rd party layer or from 3rd party git trees.
This logical separation can be affected by hardware security fixes (e.g.
related to CPU microcode) which may impact validation of userspace and many BSP
layers.
https://www.yoctoproject.org/is-yocto-project-for-you/
13. Yocto Project follows a strict release schedule incorporating security
patches in all supported releases. This predictability is crucial for projects
that are based on Yocto Project and allows the development teams to plan their
activities. Developers can choose which Yocto Project branch on which to base
their activities as a function of their needs. The development branch will
ensure access to the latest features while the stable branches will reduce the
pace of changes. CVEs (common vulnerabilities and exposures) issues are
supported for the latest 2 releases.
>> ...
>> If we are able to attract contributions, could we eventually associate YP
>> LTS external test results with public BSP definitions and hardware
>> model/revision numbers?
>
> Isn't this more a topic for the 3rd party BSP layers that are actually
> providing this hardware support?
It's about the recording of test results, e.g. it could be valuable for a new
device vendor to see centrally that YP LTS Release X.Y has been validated with
BSP1, BSP23 & BSP45, if those are similar to the new device. On x86 platforms
with very similar hardware, device firmware differences (which are not modeled
in BSP definitions), can affect test results. Hence the value of tracking
firmware variations alongside test results and hardware models.
Rich
_______________________________________________
Openembedded-architecture mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-architecture
