Change the prow badge on top of the readme file to show the status of
image building (push-image job). We're not interested in the status of
the PR builds, merely on how the tip of the master branch (or occasional
releases) are doing.
Move all content from README.md to the Jekyll site under docs/. Also
re-organize it into multiple sub-pages.
Populate README with fresh content turning it into virtually a big link
to the html-based documentation site. Spiced up with super-quick-start
instructions.
An attempt to organize the Makefile variables a bit further. The idea is
to only document variables that are really intended for build
customization and initialize all these variables in the Makefile with
'=?' so that they can be specified in the environment (and not just with
variable overrides). Thus, this patch drops some variables from the
README and change the initialization of some variables in the Makefile
so that the two files would be in sync.
make image and make push fails when trying to use an ENV VAR value, as
it is now they can only be overrided.
the Var modified are
GO_CMD
GO_FMT
IMAGE_BUILD_EXTRA_OPTS
IMAGE_BUILD_CMD
IMAGE_PUSH_CMD
IMAGE_TAG_NAME
IMAGE_REGISTRY
IMAGE_NAME
IMAGE_EXTRA_TAG_NAMES
K8S_NAMESPACE
HOSTMOUNT_PREFIX
This new behaviour has also been updated on the README.
Signed-off-by: Carlos Eduardo Arango Gutierrez <carangog@redhat.com>
This provides support for 32-bit ARM cpuid capabilities based on
the HWCAP flags, and enables the build of NFD on the 32-bit ARM
userland - notably, this also applies to ARM64 systems that are
running userspace in Aarch32 mode, which is where this problem
was first encountered.
Signed-off-by: Paul Mundt <paul.mundt@adaptant.io>
This builds on the PCI support to enable the discovery of USB devices.
This is primarily intended to be used for the discovery of Edge-based
heterogeneous accelerators that are connected via USB, such as the Coral
USB Accelerator and the Intel NCS2 - our main motivation for adding this
capability to NFD, and as part of our work in the SODALITE H2020
project.
USB devices may define their base class at either the device or
interface levels. In the case where no device class is set, the
per-device interfaces are enumerated instead. USB devices may
furthermore have multiple interfaces, which may or may not use the
identical class across each interface. We therefore report device
existence for each unique class definition to enable more fine-grained
labelling and node selection.
The default labelling format includes the class, vendor and device
(product) IDs, as follows:
feature.node.kubernetes.io/usb-fe_1a6e_089a.present=true
As with PCI, a subset of device classes are whitelisted for matching.
By default, there are only a subset of device classes under which
accelerators tend to be mapped, which is used as the basis for
the whitelist. These are:
- Video
- Miscellaneous
- Application Specific
- Vendor Specific
For those interested in matching other classes, this may be extended
by using the UsbId rule provided through the custom source. A full
list of class codes is provided by the USB-IF at:
https://www.usb.org/defined-class-codes
For the moment, owing to a lack of a demonstrable use case, neither
the subclass nor the protocol information are exposed. If this
becomes necessary, support for these attributes can be trivially
added.
Signed-off-by: Paul Mundt <paul.mundt@adaptant.io>
