Ранее, в ветке ядра 4.9 собирались драйвера Intel версии 5.2.1, в версиях 4.19 собираются старые драйвера 5.1.0 Хотелось бы чтобы и далее в ядрах std-def драйвера были 5.2.1 и свежее.
Если уж обновлять, то пожалуй весь стек интеловских драйверов: 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
