> https://www.openembedded.org/wiki/OEDVM_2021 > https://pretalx.com/yocto-project-summit-2021/talk/BVZMYW/ > 1530 UTC on Zoom (link in the URL above)
In preparation for the BSP discussion at today's OEDVM, the following background material may be helpful. Comments on BSP patterns, anti-patterns, incentives, constraints and other topics are welcome in this mailing list thread, so they can be organized ahead of the 30-minute session. 1. "How to write a really good BSP layer" -- Chris Simmonds (Feb 2020) https://www.youtube.com/watch?v=7-iKPwdjVRw (carrot) 2. "State of BSPs" -- Beth Flanagan (Feb 2020) https://www.youtube.com/watch?v=IBQCQWWOXNU (stick) 3. "Tips for Yocto BSPs" -- Cliff Brake & Khem Raj (Feb 2021) https://tmpdir.org/009/ (patterns & anti-patterns) RESOURCES * Layer index: http://layers.openembedded.org/ * BSP tracker: https://bugzilla.yoctoproject.org/describecomponents.cgi?product=BSPs * Dev guide: https://docs.yoctoproject.org/bsp-guide/index.html MINUTES OF PRIOR OE DEVELOPER MEETINGS NOV 2019 (LYON) BSPs: carrot versus stick 14:20 Crofton: How many use vendor BSPs? (show of hands) ~30% Andrey: Most fixes are not pushed back to the vendor BPSs. Scott: AGL is not prepared to get input via the layers Jan-Simon: That’s not really the case. Richard: Would it help if the BSPs were Yocto compatible? It should not change anything just when including the layer. Consensus: that would help. Mark H: Yocto compatibility is one part of the problem, the other is that the BSPs do not use the version of the kernel that he wants. Jon: The vendors also do not support old kernel releases in the Ubuntu-variant images. Mark A: They are also covering multiple boards with the same release, so the kernel is trailing. Richard: The compatibility program has not been pushed as hard as it could. Mark H: The layer index should show if a layer is Yocto Compatible. It should also be stated clearly what kernel version the BSP layer supports. Andrey: That would make it harder for the users. Marek: These BSP are more like a tech demo. Josef: They are also shipping arbitrary .bbappends. Jan-Simon: They cannot enable all BSPs at once. Friendly layers would help. Isolation is key. If they ship libc-headers, it will break a package feed. Richard: linux-libc-headers is just for building the libc, don’t use it for anything else. Scott: Some vendors with the bad BSP are yocto project members. William: The tools for checking compatibility have gotten a lot better. Scott: Koen has been talking about this for years. Richard: meta-oe doesn’t pass compatibility with Zeus right now. Mark H: Wants to use the linux-yocto recipe, for fragments and moving to a different board. Josef: There is a How to setup a BSP layer, and how to create a kernel recipe. Paul: The documentation on how to build a clean BSP layer is not understandable by the usual BSP builders. Mark H: The layerindex should show a checkmark for Yocto compatible layers. Mikko: Some vendor BSPs are not public. Mark H: Money speaks. Jan: Many vendors say that their BSP is just for evaluation purposes. OCT 2018 (EDINBURGH) Ndec: setup Google Analytics on layers.openembedded.org (and probably openembedded.org) Scott: we should run the existing checkers on known layers Marco Cavallini: Are there rules to submitting layers to the index? Some review, check that it’s reusable for other projects (yocto compatible) Crofton recommends to run yocto-check-layer (especially BSP layers) Richard: the layer-index can find problems easily which are not detected by check-layer Mark Hatle: Machine and distro checking works well Richard: check-layer uses the sstate checksums to verify that a layer affects only things that it should touch (machine/distro level) when enabled
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#1224): https://lists.openembedded.org/g/openembedded-architecture/message/1224 Mute This Topic: https://lists.openembedded.org/mt/83071169/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
