Очевидно, что текущая тенденция в ядре (поправьте меня, если я ошибся) состоит в том, чтобы встроить его в дерево устройств.
Это подтверждается несколькими драйверами, вызывающими
const void *of_get_mac_address(struct device_node *np)
{
const void *addr;
addr = of_get_mac_addr(np, "mac-address");
if (addr)
return addr;
addr = of_get_mac_addr(np, "local-mac-address");
if (addr)
return addr;
addr = of_get_mac_addr(np, "address");
if (addr)
return addr;
return of_get_mac_addr_nvmem(np);
}
в подпрограмма инициализации.
Вопрос:
Какова «лучшая практика» для сериализации в производстве?
Нормальная процедура - иметь «станцию программирования» в конце производственная линия для загрузки Fla sh (SPI NOR, в моем случае) со всеми необходимыми данными; большинство из них - stati c, но небольшую часть нужно будет «сериализовать».
В моем случае эти сериализованные данные загружаются в очень маленький раздел MTD.
Мой текущий идентификатор стратегии, чтобы получить его на этапе запуска и изменить (сгенерированный случайным образом) адрес MA C (вместе с другими данными), используя что-то вроде macchanger
.
Это, помимо того, что оно не элегантно, означает другой адрес на короткое время появится в сети.
OTOH, восстановление полной .dtb только для того, чтобы изменить адрес MA C (и найти подходящее место для его выгрузки), выглядит не лучше.
У меня есть есть идеи получше, но прежде чем я решу заново изобрести колесо, я хотел бы спросить, есть ли какая-то устоявшаяся практика для решения проблемы.