ALT Linux Bugzilla – #36863

Если уж обновлять, то пожалуй весь стек интеловских драйверов:
https://sourceforge.net/projects/e1000/files/

И да, можно собрать внешними модулями для Sisyphus, но лучше всё-таки патчами на mainline.

> И да, можно собрать внешними модулями для Sisyphus, но лучше всё-таки патчами
> на mainline.
Не лучше. Надо собрать именно отдельными модулями. Отдельные модули меньше разваливаются при обновлении ядра внутри ветки и у них понятный workflow переезда между ветками.

Если что-то живёт вне ядра и у него отдельный релизный цикл, не привязанный к ядру -- пусть будет отдельными модулями.

Отдельные модули нельзя делать для обратной совместимости - потерять доступ к серверу после обновления ядра по причине того, что ментейнер вынес модули в отдельные пакеты - недопустимо.

Как вариант - подумать на предмет зависимостей, но помоему это для ядерных модулей не работает из-за allow-duplicated.

(В ответ на комментарий №3)
> Отдельные модули нельзя делать для обратной совместимости - потерять доступ к
> серверу после обновления ядра по причине того, что ментейнер вынес модули в
> отдельные пакеты - недопустимо.

Переименовать в этих отдельных пакетах модули и положить в пакет с ними blacklist файл. Тогда их можно не выключать в ядре и при отсутствии внешнего пакета будет работать ядерная реализация.

Так или иначе, эксперимент с включением патчем модулей, имеющих отдельный релизный цикл я считаю провалившимся и повторять его не собираюсь.

> 
> Как вариант - подумать на предмет зависимостей, но помоему это для ядерных
> модулей не работает из-за allow-duplicated.

(В ответ на комментарий №4)
> (В ответ на комментарий №3)
> > Отдельные модули нельзя делать для обратной совместимости - потерять доступ к
> > серверу после обновления ядра по причине того, что ментейнер вынес модули в
> > отдельные пакеты - недопустимо.
> 
> Переименовать в этих отдельных пакетах модули и положить в пакет с ними
> blacklist файл. Тогда их можно не выключать в ядре и при отсутствии внешнего
> пакета будет работать ядерная реализация.

У меня, например, скрипты заточены на имена модулей. Это ещё хуже, чем в ядре патчем обновлять.

> 
> Так или иначе, эксперимент с включением патчем модулей, имеющих отдельный
> релизный цикл я считаю провалившимся и повторять его не собираюсь.

А мне кажется, это было очень удачно. У меня ушло около 15 минут на создание патча, это же совсем просто.

> 
> > 
> > Как вариант - подумать на предмет зависимостей, но помоему это для ядерных
> > модулей не работает из-за allow-duplicated.

А насколько будет удачным вынесение внешних драйверов сетевух при очередной смене версии ядра (типа 4.19 -> 5.0)? А до этого момента держать в виде патча.

> У меня, например, скрипты заточены на имена модулей. Это ещё хуже, чем в ядре
> патчем обновлять.
Если ты разложил себе грабли, написав скрипты, заточенные на имена модулей -- это твои грабли.
 
> А мне кажется, это было очень удачно. У меня ушло около 15 минут на создание
> патча, это же совсем просто.
А мне так не кажется. Периодически при выходе нового релиза приходится решать конфликты в этих модулях.
И выход нового ядра, на которое прежний патч, разумеется, не ляжет это не какое-то редкостное событие, а бывает раз в полтора месяца.

У нас есть хороший, удобный и работающий механизм сборки внешних модулей, их собирается множество. И только ixgb надо обязательно тащить в ядро.

(В ответ на комментарий №7)
> > У меня, например, скрипты заточены на имена модулей. Это ещё хуже, чем в ядре
> > патчем обновлять.
> Если ты разложил себе грабли, написав скрипты, заточенные на имена модулей --
> это твои грабли.

Да не я один такой. Проверка или загрузка модуля по имени это зачастую стандартная схема деплоя. 

Убирая одну проблему ты создаёшь кучу новых, главная из которых - несовместимость с апстримом.


> 
> > А мне кажется, это было очень удачно. У меня ушло около 15 минут на создание
> > патча, это же совсем просто.
> А мне так не кажется. Периодически при выходе нового релиза приходится решать
> конфликты в этих модулях.
> И выход нового ядра, на которое прежний патч, разумеется, не ляжет это не
> какое-то редкостное событие, а бывает раз в полтора месяца.

Ну и что ? Не вижу проблем раз в полтора месяца пройтись по драйверам и смержить.

Если патч перестал накладываться - это в любом случае повод заглянуть внутрь и посмотреть что происхожиди.

> 
> У нас есть хороший, удобный и работающий механизм сборки внешних модулей, их
> собирается множество. И только ixgb надо обязательно тащить в ядро.

Да если бы изначально собирали ixgbe отдельно от ядра, тотак бы и было. e1000, кстати, одно время был вне ядра, потом зачем-то втащили внутрь (что делается заметно легче).

(In reply to comment #6)

> А насколько будет удачным вынесение внешних драйверов сетевух при очередной
> смене версии ядра (типа 4.19 -> 5.0)? А до этого момента держать в виде патча.

На самом деле если момент выбирать, то это прямо сейчас, пока про p9 официально не объявлено. Переделывать в рамках бранча плохо, а вот в момент перехода с бранча на бранч - это ещё более-менее. И, всё же, лучше для всех ядер, так как бывет надо скакать бежду std-def и un-def.

Отдельно собран модуль kernel-modules-ixgbe-std-def