Это превращается в очень интересную дискуссию… Что касается изначального вопроса, то мне не известно, чтобы MT когда-либо выкладывал актуальный список поддерживаемого стороннего оборудования для конкретной версии. Но если вы вытащите squashfs-образы из NPK-файлов, можно заглянуть в содержимое /lib/modules/* и увидеть точный список модулей ядра, с которыми поставляется каждое обновление. Правда, сказать, поддерживает ли конкретная версия того или иного модуля ядра вашу сетевую карту — сложно. Например: у меня нет опыта с Realtek USB NIC, но по гуглу RTL8156 — это 2.5G USB-чипсет, и более новые версии драйвера/модуля r8152 поддерживают 8156. Судя по всему, поддержка появилась уже в нескольких мейнлайновых версиях ядра Linux после 5.6.x, которая используется в ROS7. Значит, если RTL8156 поддерживается в ROS7 на x86, то MT, видимо, портировали эту версию драйвера или поддержку нового чипсета в своё ядро. Могу подтвердить, что r8152.ko тоже есть в ARM64 версии ROS7 (в базовом пакете, не в extra-nics); однако, если USB-донгл не определяется, возможно, сборка r8152.ko для ARM64 сделана из других исходников, чем для x86? (Хотя это было бы странно, на мой взгляд.) Также могу подтвердить, что extra-nics не включает никаких дополнительных драйверов для USB NIC.
Кстати, для справки: хотя в ROS6 «x86» и «CHR» релизы были немного более различимы, чем в ROS7, даже в ROS6 различиями было то, какое ядро используется, а не разные сборки «x86» и «CHR». В ROS6 x86 поставлялся с тремя ядрами (и тремя наборами модулей): 32-битный однопроцессорный, 32-битный SMP и 64-битный SMP. 64-битное SMP-ядро дебютировало с CHR (кстати, ROS6 CHR был только для x86_64), но при этом шло и во всех последующих «x86» сборках; просто обычно оно было скрыто, если не запускали релиз CHR. У 64-битного ядра было больше драйверов, чем у 32-битного (например, PV NIC драйверы для различных гипервизоров), и была возможность включить 64-битное ядро при установке на «голый» металл, чтобы использовать дополнительную поддержку драйверов x86_64 (то есть можно было, например, в виртуальной машине поставить обычный «x86», лицензировать его и переключиться на 64-битное ядро, получив все возможности CHR, включая работу PV NIC для любимых гипервизоров). В ROS7 же поддержка драйверов для «x86» и «CHR»统一, и, по моему мнению, «x86» теперь только 64-битный.
Очень хотелось бы понять, что именно имел в виду автор того сообщения. Когда я читал, мне показалось, что он говорит, что действительно пишет чистый образ CHR на SD-карту и успешно загружает его на «голом» железе. Но, похоже, @sirbryan понял это иначе и ответил, будто это был вопрос о том, что возможно, а не утверждение, что это возможно.
У меня нет доступа к стороннему ARM64 оборудованию, чтобы проверить лично. Но если есть не-Ampere ARMv8 платформы, на которых ARM64 версия ROS может загрузиться на «голом» железе, это меняет всю картину! Как подмечает sirbryan, даже если в ARM64 ROS нет зависимостей от Ampere-специфичных инструкций и нет runtime-проверок, подтверждающих запуск на Ampere или официальном устройстве RB/CCR, для работы на любом стороннем одноплатном компьютере понадобится поддержка UEFI на этом железе.
Раньше на x86 я пытался запускать образ CHR на «голом» железе, и это не работало. Похоже, что MT добавили проверки, не является ли система гостем гипервизора, и если проверка не проходит, загрузка искусственно прерывается. У меня нет возможности проверить это для CHR-ARM64, но я не удивлюсь, если там ситуация такая же. Очень жаль, потому что разница между CHR и обычным режимом почти отсутствует — и там, и там используются одни и те же ядра, бинарники, squashfs-образы. Хотя я пока не нашёл местонахождение этого параметра, похоже, где-то на файловой системе установлен флаг, который говорит ROS, работает ли он в режиме «CHR» или «legacy». Единственное реальное отличие — лицензирование. Есть плюсы и минусы в обеих моделях, и было бы здорово дать возможность использовать лицензии CHR при установке на «голое» железо, потому что у CHR есть бонус — лицензии можно переносить. Честно говоря, не понимаю, чем могло бы рисковать MT, разрешая выбирать лицензирование CHR на bare-metal… Какая угроза их бизнес-модели?
Конечно, у разных людей разные цели, когда они запускают виртуальный роутер — все они имеют право на своё мнение. Ваша цель — скрыть различия в аппаратуре — это вполне справедливо. Но virtio/PV интерфейсы и драйверы имеют свои недостатки, в частности, они обычно менее производительны, чем прямое взаимодействие с железом через нативные драйверы. Поэтому те, кто хочет использовать один хост для разных задач и запускать несколько гостевых систем с виртуализацией (один из которых — роутер), но при этом выжать максимум производительности, могут выделять сетевое оборудование гостю напрямую, передавая ему определённые интерфейсы. Есть ещё SR-IOV — своего рода «лучший из обоих миров» вариант, когда сетевой адаптер можно разделить между гостями без накладных расходов паравиртуализации, но это ограничено PCIe, и требует поддержки и со стороны самого PCIe-устройства, и со стороны драйвера гостя (каждый SR-IOV-совместимый сетевой интерфейс имеет свой драйвер на хосте и госте, специфичный для производителя).
