1
0
Fork 0
mirror of https://github.com/kubernetes-sigs/node-feature-discovery.git synced 2024-12-14 11:57:51 +00:00
node-feature-discovery/source/usb/utils.go

130 lines
3.7 KiB
Go
Raw Permalink Normal View History

usb: Add support for USB device discovery 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>
2020-05-14 20:32:55 +00:00
/*
Copyright 2020-2021 The Kubernetes Authors.
usb: Add support for USB device discovery 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>
2020-05-14 20:32:55 +00:00
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
*/
package usb
usb: Add support for USB device discovery 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>
2020-05-14 20:32:55 +00:00
import (
"fmt"
"os"
usb: Add support for USB device discovery 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>
2020-05-14 20:32:55 +00:00
"path"
"path/filepath"
"strings"
"k8s.io/klog/v2"
usb: Add support for USB device discovery 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>
2020-05-14 20:32:55 +00:00
nfdv1alpha1 "sigs.k8s.io/node-feature-discovery/api/nfd/v1alpha1"
"sigs.k8s.io/node-feature-discovery/pkg/utils/hostpath"
)
usb: Add support for USB device discovery 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>
2020-05-14 20:32:55 +00:00
var devAttrs = []string{"class", "vendor", "device", "serial"}
usb: Add support for USB device discovery 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>
2020-05-14 20:32:55 +00:00
// The USB device sysfs files do not have terribly user friendly names, map
// these for consistency with the PCI matcher.
var devAttrFileMap = map[string]string{
"class": "bDeviceClass",
"device": "idProduct",
"vendor": "idVendor",
"serial": "serial",
usb: Add support for USB device discovery 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>
2020-05-14 20:32:55 +00:00
}
func readSingleUsbSysfsAttribute(path string) (string, error) {
data, err := os.ReadFile(path)
usb: Add support for USB device discovery 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>
2020-05-14 20:32:55 +00:00
if err != nil {
2024-01-22 20:45:15 +00:00
return "", fmt.Errorf("failed to read device attribute %s: %w", filepath.Base(path), err)
usb: Add support for USB device discovery 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>
2020-05-14 20:32:55 +00:00
}
attrVal := strings.TrimSpace(string(data))
return attrVal, nil
}
// Read a single USB device attribute
// A USB attribute in this context, maps to the corresponding sysfs file
func readSingleUsbAttribute(devPath string, attrName string) (string, error) {
return readSingleUsbSysfsAttribute(path.Join(devPath, devAttrFileMap[attrName]))
}
// Read information of one USB device
func readUsbDevInfo(devPath string) ([]nfdv1alpha1.InstanceFeature, error) {
instances := make([]nfdv1alpha1.InstanceFeature, 0)
attrs := make(map[string]string)
usb: Add support for USB device discovery 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>
2020-05-14 20:32:55 +00:00
for _, attr := range devAttrs {
usb: Add support for USB device discovery 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>
2020-05-14 20:32:55 +00:00
attrVal, _ := readSingleUsbAttribute(devPath, attr)
if len(attrVal) > 0 {
attrs[attr] = attrVal
usb: Add support for USB device discovery 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>
2020-05-14 20:32:55 +00:00
}
}
// USB devices encode their class information either at the device or the interface level. If the device class
// is set, return as-is.
if attrs["class"] != "00" {
instances = append(instances, *nfdv1alpha1.NewInstanceFeature(attrs))
usb: Add support for USB device discovery 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>
2020-05-14 20:32:55 +00:00
} else {
// Otherwise, if a 00 is presented at the device level, descend to the interface level.
interfaces, err := filepath.Glob(devPath + "/*/bInterfaceClass")
if err != nil {
return nil, err
usb: Add support for USB device discovery 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>
2020-05-14 20:32:55 +00:00
}
// A device may, notably, have multiple interfaces with mixed classes, so we create a unique device for each
// unique interface class.
for _, intf := range interfaces {
// Determine the interface class
attrVal, err := readSingleUsbSysfsAttribute(intf)
if err != nil {
return nil, err
usb: Add support for USB device discovery 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>
2020-05-14 20:32:55 +00:00
}
subdevAttrs := make(map[string]string, len(attrs))
for k, v := range attrs {
subdevAttrs[k] = v
usb: Add support for USB device discovery 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>
2020-05-14 20:32:55 +00:00
}
subdevAttrs["class"] = attrVal
usb: Add support for USB device discovery 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>
2020-05-14 20:32:55 +00:00
instances = append(instances, *nfdv1alpha1.NewInstanceFeature(subdevAttrs))
usb: Add support for USB device discovery 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>
2020-05-14 20:32:55 +00:00
}
}
return instances, nil
usb: Add support for USB device discovery 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>
2020-05-14 20:32:55 +00:00
}
// detectUsb detects available USB devices and retrieves their device attributes.
func detectUsb() ([]nfdv1alpha1.InstanceFeature, error) {
usb: Add support for USB device discovery 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>
2020-05-14 20:32:55 +00:00
// Unlike PCI, the USB sysfs interface includes entries not just for
// devices. We work around this by globbing anything that includes a
// valid product ID.
devPathGlob := hostpath.SysfsDir.Path("bus/usb/devices/*/idProduct")
devPaths, err := filepath.Glob(devPathGlob)
usb: Add support for USB device discovery 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>
2020-05-14 20:32:55 +00:00
if err != nil {
return nil, err
}
// Iterate over devices
devInfo := make([]nfdv1alpha1.InstanceFeature, 0)
for _, devPath := range devPaths {
devs, err := readUsbDevInfo(filepath.Dir(devPath))
usb: Add support for USB device discovery 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>
2020-05-14 20:32:55 +00:00
if err != nil {
klog.ErrorS(err, "failed to read USB device info")
usb: Add support for USB device discovery 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>
2020-05-14 20:32:55 +00:00
continue
}
devInfo = append(devInfo, devs...)
usb: Add support for USB device discovery 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>
2020-05-14 20:32:55 +00:00
}
return devInfo, nil
}