Примерно через сутки после релиза ядра Linux 5.10 сформирован корректирующий релиз 5.10.1, в котором отменены два изменения в подсистемах md и dm raid, в которых всплыли проблемы. Первое изменение касалось перевода типа переменной chunk_sectors с int на unsigned, а второе изменяло лимит на выполнение операции  discard для raid1 и raid10...

Подробнее: https://www.opennet.dev/opennews/art.shtml?num=54257

• Обновление ядра Linux 5.10.1 с исправлениями по горячим след...,Аноним, 09:12 , 15-Дек-20
  • Обновление ядра Linux 5.10.1 с исправлениями по горячим след...,_hide_, 09:29 , 15-Дек-20
    • Обновление ядра Linux 5.10.1 с исправлениями по горячим след...,Аноним, 10:02 , 15-Дек-20
    • Обновление ядра Linux 5.10.1 с исправлениями по горячим след...,Аноним, 20:53 , 15-Дек-20
  • Обновление ядра Linux 5.10.1 с исправлениями по горячим след...,Z, 10:11 , 15-Дек-20
  • Обновление ядра Linux 5.10.1 с исправлениями по горячим след...,Ordu, 10:31 , 15-Дек-20
    • Обновление ядра Linux 5.10.1 с исправлениями по горячим след...,Аноним, 10:49 , 15-Дек-20
      • Обновление ядра Linux 5.10.1 с исправлениями по горячим след...,fyjybvec, 05:12 , 16-Дек-20
    • Обновление ядра Linux 5.10.1 с исправлениями по горячим след...,Аноним, 13:55 , 15-Дек-20
  • Обновление ядра Linux 5.10.1 с исправлениями по горячим след...,n00by, 10:53 , 15-Дек-20
  • Обновление ядра Linux 5.10.1 с исправлениями по горячим след...,snmp agent, 17:13 , 15-Дек-20
  • Обновление ядра Linux 5.10.1 с исправлениями по горячим след...,Аноним, 00:25 , 16-Дек-20
• Обновление ядра Linux 5.10.1 с исправлениями по горячим след...,Аноним, 09:13 , 15-Дек-20
  • Обновление ядра Linux 5.10.1 с исправлениями по горячим след...,Dzen Python, 09:33 , 15-Дек-20
    • Обновление ядра Linux 5.10.1 с исправлениями по горячим след...,iPony129412, 09:40 , 15-Дек-20
• Обновление ядра Linux 5.10.1 с исправлениями по горячим след...,leibniz, 09:13 , 15-Дек-20
  • Обновление ядра Linux 5.10.1 с исправлениями по горячим след...,Рмшъ, 09:49 , 15-Дек-20
  • Обновление ядра Linux 5.10.1 с исправлениями по горячим след...,Аноним, 10:35 , 15-Дек-20
    • Обновление ядра Linux 5.10.1 с исправлениями по горячим след...,zzz, 12:49 , 15-Дек-20
      • Обновление ядра Linux 5.10.1 с исправлениями по горячим след...,Аноним, 13:16 , 15-Дек-20
        • Обновление ядра Linux 5.10.1 с исправлениями по горячим след...,Аноним, 14:54 , 15-Дек-20
      • Обновление ядра Linux 5.10.1 с исправлениями по горячим след...,анонимус, 16:34 , 15-Дек-20
    • Обновление ядра Linux 5.10.1 с исправлениями по горячим след...,Урри, 13:55 , 16-Дек-20
  • Обновление ядра Linux 5.10.1 с исправлениями по горячим след...,КО, 11:03 , 15-Дек-20
  • Обновление ядра Linux 5.10.1 с исправлениями по горячим след...,Michael Shigorin, 00:54 , 16-Дек-20
• Обновление ядра Linux 5.10.1 с исправлениями по горячим след...,Аноним, 09:18 , 15-Дек-20
  • Обновление ядра Linux 5.10.1 с исправлениями по горячим след...,Аноним, 09:21 , 15-Дек-20
  • Обновление ядра Linux 5.10.1 с исправлениями по горячим след...,mikhailnov, 09:50 , 15-Дек-20
    • Обновление ядра Linux 5.10.1 с исправлениями по горячим след...,Cyber100, 18:27 , 15-Дек-20
• Обновление ядра Linux 5.10.1 с исправлениями по горячим след...,iPony129412, 09:21 , 15-Дек-20
  • Обновление ядра Linux 5.10.1 с исправлениями по горячим след...,Корец, 20:27 , 15-Дек-20
• Обновление ядра Linux 5.10.1 с исправлениями по горячим след...,Slowpoke, 09:31 , 15-Дек-20
  • Обновление ядра Linux 5.10.1 с исправлениями по горячим след...,Аноним, 09:34 , 15-Дек-20
• Обновление ядра Linux 5.10.1 с исправлениями по горячим след...,Fracta1L, 10:01 , 15-Дек-20
  • Обновление ядра Linux 5.10.1 с исправлениями по горячим след...,Аноним, 10:13 , 15-Дек-20
  • Обновление ядра Linux 5.10.1 с исправлениями по горячим след...,Аноним, 10:33 , 15-Дек-20
• Обновление ядра Linux 5.10.1 с исправлениями по горячим след...,Аноним, 11:11 , 15-Дек-20
  • Обновление ядра Linux 5.10.1 с исправлениями по горячим след...,Аноним, 12:00 , 15-Дек-20
• Обновление ядра Linux 5.10.1 с исправлениями по горячим след...,RM, 13:47 , 15-Дек-20
• Обновление ядра Linux 5.10.1 с исправлениями по горячим след...,Аноним, 14:46 , 15-Дек-20
  • Обновление ядра Linux 5.10.1 с исправлениями по горячим след...,Урри, 13:59 , 16-Дек-20
• Обновление ядра Linux 5.10.1 с исправлениями по горячим след...,Аноним, 15:00 , 15-Дек-20
  • Обновление ядра Linux 5.10.1 с исправлениями по горячим след...,Аноним, 15:10 , 15-Дек-20
    • Обновление ядра Linux 5.10.1 с исправлениями по горячим след...,Аноним, 10:28 , 16-Дек-20
      • Обновление ядра Linux 5.10.1 с исправлениями по горячим след...,Аноним, 15:46 , 16-Дек-20
        • Обновление ядра Linux 5.10.1 с исправлениями по горячим след...,Аноним, 21:55 , 16-Дек-20
• Обновление ядра Linux 5.10.1 с исправлениями по горячим след...,Аноним, 17:14 , 15-Дек-20
  • Обновление ядра Linux 5.10.1 с исправлениями по горячим след...,Корец, 20:28 , 15-Дек-20
    • Обновление ядра Linux 5.10.1 с исправлениями по горячим след...,Аноним, 20:45 , 15-Дек-20
      • Обновление ядра Linux 5.10.1 с исправлениями по горячим след...,Корец, 21:11 , 15-Дек-20
        • Обновление ядра Linux 5.10.1 с исправлениями по горячим след...,Аноним, 23:03 , 15-Дек-20
          • Обновление ядра Linux 5.10.1 с исправлениями по горячим след...,Аноним, 00:34 , 16-Дек-20
            • Обновление ядра Linux 5.10.1 с исправлениями по горячим след...,Аноним, 02:43 , 16-Дек-20
              • Обновление ядра Linux 5.10.1 с исправлениями по горячим след...,Соня Мармеладова, 03:29 , 16-Дек-20
                • Обновление ядра Linux 5.10.1 с исправлениями по горячим след...,Аноним, 21:49 , 16-Дек-20
        • Обновление ядра Linux 5.10.1 с исправлениями по горячим след...,llolik, 23:14 , 15-Дек-20
          • Обновление ядра Linux 5.10.1 с исправлениями по горячим след...,Аноним, 02:47 , 16-Дек-20
            • Обновление ядра Linux 5.10.1 с исправлениями по горячим след...,Аноним, 04:05 , 16-Дек-20
          • Обновление ядра Linux 5.10.1 с исправлениями по горячим след...,Урри, 16:34 , 16-Дек-20
            • Обновление ядра Linux 5.10.1 с исправлениями по горячим след...,llolik, 17:16 , 16-Дек-20
      • Обновление ядра Linux 5.10.1 с исправлениями по горячим след...,llolik, 23:22 , 15-Дек-20
• Обновление ядра Linux 5.10.1 с исправлениями по горячим след...,YMM, 00:58 , 16-Дек-20
• Обновление ядра Linux 5.10.1 с исправлениями по горячим след...,Аноним, 03:24 , 17-Дек-20
  • Обновление ядра Linux 5.10.1 с исправлениями по горячим след...,Аноним, 18:13 , 18-Дек-20

А зачем вообще если сразу понятно что переменная никогда не примет отрицательное значение не применять тип unsigned?

Вы вообще исходники чужие когда-нибудь читали? Это ещё цветочки -- к ошибкам не приводит и ладно.

Там приводит к варнингам компиляции - потому и попытались исправить :)

Полезли исправлять и привело. Значит там знаковое должно быть.

Это же классический Unix-style использовать int

А зачем вообще, если сразу понятно, что переменная не примет значение больше чем 2^31-1, применять тип int?

Судя по названию для chunk_sectors unsigned short все-таки не хватит, так что на мой взгляд оптимально использовать тип uint32_t (да, это из libc, но у него должен быть свой аналог в ядре).

да, u32 называется.

> А зачем вообще, если сразу понятно, что переменная не примет значение больше чем 2^31-1, применять тип int?

Дэниел Бернштейн, залогиньтесь!

Например, что бы использовать недействительное значение как индикатор ошибки.

Например, чтобы можно было их вычитать

> если сразу понятно

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

Патч нулевого дня? В моем линуксе?

Радовался бы, что не через полгода.
А на деле большинство юзеров это даже и не заметят - им ядро прилетит уже с пачем в дистро.
Пусть правят.

Ну типа того.
Даже пионеры с Ubuntu 20.10 ещё на 5.8 сидят и будут пока сидеть.

и это LTS

Вот и поддерживают

Это не лтс. Он будет лтс, когда подлатают все косяки. Это текущая ветка, а на ней всегда проблем больше (сроки поджимают и нет времени rc вылизать, наверное).

LTS, LTS. Прост все так рвались пропихнуть свои поделия в LTS-релиз, что теперь еще пару лет будут отлаживать.

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

Да, но помню местные анонимусы ругали ноду за похожий подход - там тоже LTS идет позднее от stable. Пытались доказать, что так больше никто не делает. А тут само ядро. Также ведь многие проекты первый мажорный релиз вообще помечают как пробный - GCC и Mesa, к примеру. Все же местная богема тут очень некомпетентна.

Оно получит статус LTS только после выпуска следующей ветки.

Какие сроки, вы о чем?
Все прекрасно работает, критически важных не реализованных вещей нет - можно сосредоточиться на тестировании.

Но нет, всеобщая современная болезнь "пускай тестируют на себе юзеры" и сюда проникла.

Сам вякнул, сам заплюсовал.
Последний LTS 5.4

Так в них как раз и пытаются запихнуть побольше, побольше...

Как в кубунте 20.04 обновить? ukku, ошибку выдаёт...

Ты из исходников или из готового бинарного пакета?

Открываете https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.10.1/
Скачиваете:
linux-headers-5.10.1-051001-generic_5.10.1-051001.202012142031_amd64.deb
linux-headers-5.10.1-051001_5.10.1-051001.202012142031_all.deb
linux-image-unsigned-5.10.1-051001-generic_5.10.1-051001.202012142031_amd64.deb
linux-modules-5.10.1-051001-generic_5.10.1-051001.202012142031_amd64.deb
и делаете sudo apt install ./*.deb
Это то, что делает UKUU. Но там, смотрю, перед именами файлов появился префикс с архитектурой, раньше его не было, вероятно, из-за этого UKUU отвалился.

dpkg -i *.deb

Mozilla стайл

Это если бы на расте переписывать начали бы.

ребят, а когда уже лтс с поддержкой wireguard? Сидеть на мимопроходящем ядре немного некомфортно

5.10 - это LTS с поддержкой Wireguard.

Ну вы знаете, эти виртуозные сишные программисты)

Это же просто фистинг какой-то! 🤜😬

По крайней мере, эти виртуозные программисты что-то пишут и чинят, а не как Фракталы-растоманы - только языком трепать.

QA/QC в ядре? Не слышали.

QA/QC в современном мире? Не, слышали.

Так вот почему гугл вчера лежал - это они ядро свежеее накатили...

Это из-за этой ошибки Гугл прилег? А порнхаб потерял больше половины видео?

Порнхаб удалил миллионы видео потому, что с ними отказались работать виза и мастеркард. А они отказались работать потому, что какой-то журнализд откопал в порнхабовских закромах залитое в древние времена анонимом цп.

Порнхаб обиделся и выпилил всю годноту - типа если вы не хотите хорошей анонимной домашней порнушки, то вот вам стертые до дыр скучные бл_ди.

При этом, что характерно, на откровенный инцест всем моралфагам почему-то наплевать.

5.10.1 на amdgpu уходит в черный экран

5.10.2 раскроет потенциал АМД

Ага, после того как Linus прямо послал нвидию на..й выбора уже и нет. штеуд не в счет, га#но еще то

Да, Линус послал НВидию, но уже после того как НВидиа послала сообщество разработчиков ядра на 3 буквы.

>уже после того как НВидиа послала сообщество разработчиков ядра на 3 буквы.

Вот и надо было пойти

За использование int давно пора выгонять.

Что следует использовать вместо?

> Что следует использовать вместо?

int8_t, uint8_t, int16_t, uint16_t, int32_t, uint32_t, int64_t, uint64_t, size_t, ssize_t.

Аргументы?

> Аргументы?

Т. е. использование int'а для перечисления или обозначения количества элементов не вызывает чувства нелогичности?

Вызывает. Но действительность несколько шире.

man -s2 read

Предложите вариант для - считали Н байт, считали 0 байт, ошибка.
Qus_EC_t ? GetLastError()?

>> man -s2 read
>       ssize_t read(int fd, void *buf, size_t count);
>> Предложите вариант для - считали Н байт, считали 0 байт, ошибка.

typedef size_t RetVal;

RetVal read(size_t pFD, uint8_t* const pBuf, size_t pToRead, size_t* const pRead);

/******/
RetVal rv;
size_t really_read;

if(MyToRead > 0)
{
    rv = read(MyFD, MyBuf, MyToRead, &really_read);
    if(rv != RV_Ok)/* RV_Ok == 0 */
    {
        ErrorHandler...
    }
    else if(really_read < MyToRead)
    {
        EmptySourceHandler...
    }
}

Если чтение не блокирующее, то really_read вполне легально может быть меньше чем MyToRead.

Абсолютно верно. Или файл может закончится.

Размерность int не обязана быть 4 байта. При кроссплатформенной сборке можно запросто получить внезапные integer overflow на пустом месте и потом долго и упорно их искать. *_t типы - гарантировано той размерности, которая указана.

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

Дополню. Если используется gcc и платформа AVR, то там int - сюрприз, сюрприз - имеет 16 бит. Почему? Разработчик "бэкенда" так захотел. Но есть волшебный ключ "-mint8", который приводит int к правильному размеру - 8 бит.

> Если используется gcc и платформа AVR, то там int - сюрприз, сюрприз - имеет 16 бит. Почему?

Потому что по стандарту

> The minimum size for char is 8 bits, the minimum size for short and int is 16 bits, for long it is 32 bits and long long must contain at least 64 bits.
> -- https://en.wikipedia.org/wiki/C_data_types

Дабы не грешили на вику, скажу, что такое же утверждение (кроме long long, и относительно C++) я находил в третьем издании книги Страуструпа по C++ (описывающей стандарт 98 года).

> Но есть волшебный ключ "-mint8", который

ломает переносимость. Но, откровенно говоря, софт для AVR вряд ли кто-то будет пускать на серверах и/или десктопах, да и переносимость "в бОльшую сторону" (в минимум-16-битный int вместо 8-битного) в 99% случаев "сама получится".

Вы согласны под разные платформы писать разный код? Вручную выбирать размер машинного слова под конкретное устройство?

Или все же лучше оставить это решение за компилятором? Который лучше знает, какой именно размер типа будет более быстрый в данной ситуации. Ну вот поэтому и появился тип int, который "минимум 16 бит" и все остальные.

Неужели вы считаете что Керниган и Риччи были глупее вас?

> Вы согласны под разные платформы писать разный код?

Как раз наоборот я могу быть уверен, что , например, int32_t всегда строго 4 байта, а не ХЗ сколько. И что в size_t гарантировано влезет размер буфера, не вломив мне integer overflow.
> Вручную выбирать размер машинного слова под конкретное устройство?

Вот как раз *_t от этого и избавляют
> Или все же лучше оставить это решение за компилятором?

Нет, не всегда это лучше.
> вот поэтому и появился тип int, который "минимум 16 бит"

А может быть и не 16, а может быть и 32 и 64 и, с ключами, как выше написано, даже 8. И что? А потом тебе приходит бинарник/сообщение в котором, условно 15 полей типа int. И? Какого int прислали 16/32/64/... бит и каким разбирать?
> Неужели вы считаете что Керниган и Риччи были глупее вас?

Как там у Вас в 70-х? Стандарт как-бы уже давно ушёл вперёд.

> ssize_t

Только с оговоркой, что это POSIX, а не ISO/IEC.
Хотя в msvc тоже есть костыль

#if defined(_MSC_VER)
    #include <BaseTsd.h>
    typedef SSIZE_T ssize_t;
#endif

Серьёзный подход к разработке!

Киберпанк потянет?

процесс сборки с ворнингами иероглифами можно использовать в световом оформлении мс-тусовок