[sisyphus] Готовится обновления ядра std-def на 5.4 (ixgbe!)

[Anton Farygin]

On 13.02.2020 12:47, Aleksey Novodvorsky wrote:
>
>
>
> чт, 13 февр. 2020 г., 12:40 Anton Farygin <rider на basealt.ru 
> <mailto:rider на basealt.ru>>:
>
>     On 13.02.2020 12:39, Aleksey Novodvorsky wrote:
>     >
>     >
>     >
>     >
>     > чт, 13 февр. 2020 г., 12:03 Anton Farygin <rider на basealt.ru
>     <mailto:rider на basealt.ru>
>     > <mailto:rider на basealt.ru <mailto:rider на basealt.ru>>>:
>     >
>     >     On 12.02.2020 16:50, Anton V. Boyarshinov wrote:
>     >     > В Fri, 7 Feb 2020 17:11:30 +0300
>     >     > "Anton V. Boyarshinov" <boyarsh на altlinux.org
>     <mailto:boyarsh на altlinux.org>
>     >     <mailto:boyarsh на altlinux.org <mailto:boyarsh на altlinux.org>>>
>     пишет:
>     >     >
>     >     >> В задании #245508 более-менее подготовлена сборка ядра
>     std-def 5.4.
>     >     >> Там ожидается ещё одна пересборка для преодоления
>     наследования, но
>     >     >> существенных изменений, скорее всего, уже не будет.
>     >     > После обсуждений было сделано иначе:
>     >     > * in-tree модуль ixgbe в этой сборке ядра переименован,
>     чтоб не
>     >     попадал под blacklist
>     >     > * конфликт на kernel-modules-ixgbe-std-def убран, то есть в
>     >     крайнем случае на машине останутся работоспособные ядра
>     >     >
>     >     > Если не поступит весомых возражений против такой схемы, ядро
>     >     уйдёт в Сизиф завтра. Для p9, видимо, будем по возможности ждать
>     >     выходя ixgbe для 5.4
>     >     К счастью, я не настолько самоубийца, что бы использовать
>     Sisyphus
>     >     там,
>     >     где есть ixgbe/ixgbevf, но данное предложение всё равно что-то
>     >     кому-то
>     >     может сломать в новых ядрах.
>     >
>     >     Но на будущее надо как-то плавно убрать этот хак с
>     переименованным
>     >     внешнем модулем, собрав его патчем in-tree.
>     >     По этой причине я ещё не переводил ни одного сервера с
>     >     виртуализацией с
>     >     p8 на p9 (что бы в дальнейшем проблем избежать при обновлениях).
>     >
>     >
>     > Не стоит ли нам подумать о разных сборках ядер для сервера
>     > виртуализации и прочих продуктов?
>
>     Стоит подумать о разделении ядра на серверное и десктопное.
>
>
> Не уверен. Я бы принципиально отделился виртуализации от сервера 
> общего назначения. Как продукты, конечно.

Что бы понять суть твоего предложения надо взглянуть на разницу в 
предполагаемой конфигурации ядер.

А сервера от виртуализации отделять вообще сейчас нельзя. Даже в 
виртуальных машинах мы запускаем виртуальные машины.