Приветствую,

Итак, исходные данные: SoC bcm5358, внутри CPU и 5-портовый ethernet switch, соедиенный с процессором по внутреннему MII порту; встроенный linux, ядро 2.6.22

В данный момент драйвер свитча от производителя реализован так, что со стороны ОС виден один интерфейс eth0 (как раз тот, через который соединяется с внутренним 5-портовым свитчом), что вполне логично. Драйвер также поддерживает vlan и разделяет порты по группам на основании параметров, передаваемых ему.

К SoC будет подключен внешний 24-портовый чип, задействуя 2 порта внутреннего свитча. Эти два внутренних порта предполагается использовать как WAN и LAN интерфейсы соответственно, внутренний MII так и останется, остальные порты исользованы не будут.

IMHO самый простой вариант это модифицировать драйвер внутреннего свитча так, чтобы каждый порт представлялся как отдельный интерфейс (eth0 для физического порта 0, eth0 для 1 и т.д.), что позволит назначать ip адреса и пр. В последних ядрах есть такая фича как DSA (distributede switch architecture) от Marvell и там как раз каждый порт представлен своей struct net_device и сделан маппинг на физический phy через phy_bus инфраструктуру. Но в моем ядре этого нет.

Собственно - правильный ли это подход и будет ли работать такая конструкция? Может быть есть более простое решение ?

Спасибо.

вот это я не понял, представьте каждый порт как net_device, чего нет в ядре?

а вообще какие могут быть ещё варианты, если нужны два порта для разных подсетей и маршрутизация между ними?

ну или оставить один интерфейс и сделать две vlan, а уж как вы будете поступать дальше с тегированными пакетами смотрите сами

[Думаю, лучше спросить в этой же ветке, чтобы не плодить сущности ]


На девайсе к процессору подключен 24-портовый свитч, управление свитчом сделано через gpio посредством шины аналогичной MDC/MDIO (эта шина предоставляется свитчом; написан драйвер, который предоставляет функции чтения/записи ноги через ioctl).

Нужно отслеживать в snmp-агенте статус портов (up/down).

Мне видятся два варианта:

(1) читать из агента, например каждую секунду, портовые регистры свитча и получать оттуда текущий статус линка. Это IMHO будет очень накладно из-за постоянного преключения контекста (ioctl->драйвер->...)

(2) Свитч поддерживает специально выделенную ногу для сообщения прерываний процу об определенных событиях (маска задается регистром свитча), в том числе и статус линка. Завести эту ногу на gpio процессора, написать драйвер чтения ноги и какой-нибудь интерфейс в юзер-спейс (например /proc/switch/link) - т.е. линк сменился, получили прерывание, в агенте получили статус через I/O, далее все-равно нужно читать регистр, чтобы узнать какой порт сменил статус. Небольшое преимущество - читаем только /proc.

Что можете сказать по этим двум вариантам, может быть я что-то упускаю?
Спасибо!