summaryrefslogtreecommitdiff
path: root/config/u-boot/x86/patches/0008-scripts-dtc-pylibfdt-libfdt.i_shipped-Use-SWIG_Appen.patch
diff options
context:
space:
mode:
authorLeah Rowe <leah@libreboot.org>2025-01-05 08:56:23 +0000
committerLeah Rowe <leah@libreboot.org>2025-01-05 08:56:23 +0000
commite8336bcc3caaa7c3dad1d8e2324ba8977bf5aadb (patch)
treea922f6ea273da5d8ed536aa9309fd2b8ae8e8b2e /config/u-boot/x86/patches/0008-scripts-dtc-pylibfdt-libfdt.i_shipped-Use-SWIG_Appen.patch
parent63f4578263897ddca3f1ce43db7c20a49a0c0c0c (diff)
vendor.sh: Proper semantics on prefix file namesHEADmaster
They may not actually always be binary blobs, at least not software. I started referring to these as "vendor files" some time ago, for this reason. With this terminology, it applies properly to any sort of file from the vendor. For example, it may be that in the future, we start inserting the MFS section of an an Intel ME image, into the Intel ME. We already do that with deguard for example (set MFS config), on MEv11 based setup. That is a vendor *file*, and though it may still actually be a binary blob, it's not software, but configuration. The term "blob" normally means compiled software, in most people's minds, but the term blob is technically accurate for any blob, not just software; however, we have to keep people's perception in mind. Whereas, "vendor file" is also understood by most people to include code supplied by the vendor. We haven't done any releases yet with this ROM image file name prefix, so it's perfectly OK to handle it now, without handling the old one for backwards compatibility. Signed-off-by: Leah Rowe <leah@libreboot.org>
Diffstat (limited to 'config/u-boot/x86/patches/0008-scripts-dtc-pylibfdt-libfdt.i_shipped-Use-SWIG_Appen.patch')
0 files changed, 0 insertions, 0 deletions