diff options
author | Leah Rowe <leah@libreboot.org> | 2025-01-05 08:56:23 +0000 |
---|---|---|
committer | Leah Rowe <leah@libreboot.org> | 2025-01-05 08:56:23 +0000 |
commit | e8336bcc3caaa7c3dad1d8e2324ba8977bf5aadb (patch) | |
tree | a922f6ea273da5d8ed536aa9309fd2b8ae8e8b2e /config/u-boot/default/patches/0009-scripts-dtc-pylibfdt-libfdt.i_shipped-Use-SWIG_Appen.patch | |
parent | 63f4578263897ddca3f1ce43db7c20a49a0c0c0c (diff) |
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/default/patches/0009-scripts-dtc-pylibfdt-libfdt.i_shipped-Use-SWIG_Appen.patch')
0 files changed, 0 insertions, 0 deletions