В ядро не так просто попасть

Написать солидный модуль в ядро и добавить поддержку кода, скомпилированного другим компилятором - разные по сложности проекты. Кроме того, насколько я помню раст добавили не столько по техническим причинам, а на волне хайпа. Примерно во время добавления раста Торвальдса хотели скэнселить из проекта (как Столлмана) за прямолинейные разговоры, и он уходил в месячный отпуск (на фоне обвинений в стиле ‘i feel not comfortable contributing to the project’).

А вот есть пример, bcachefs. copy-on-write FS, разработана уже в 2015г., и никак не может попасть в главную ветку.

Есть пять стандартов…

Но, не переживайте, прогнозы хорошие, вот-вот, попадёт.

Насколько я понял там сейчас претензия в том, что автор не предлагал патч в linux-next, а сразу в конкретный релиз ядра хочет впихнуть. И у Линуса на этом фоне бомбануло

reiserfs тоже не в ядре, и zfs и много чего еще. Что теперь?

Не попасть в ядро могут не только лишь все. А к bcachefs сейчас предъявляются претензии по несоблюдению рыгламента, а не технического характера. Как только автор в хату правильно зайдёт ему сразу шконкоместо выдадут.

zfs по другим причинам не в ядре, его бы взяли, если бы могли, да нельзя.

4-ка вроде не в ядре.
а так:

$ tree linux-6.5.1/fs/reiserfs
linux-6.5.1/fs/reiserfs
├── acl.h
├── bitmap.c
├── dir.c
├── do_balan.c
├── file.c
├── fix_node.c
├── hashes.c
├── ibalance.c
├── inode.c
├── ioctl.c
├── item_ops.c
├── journal.c
├── Kconfig
├── lbalance.c
├── lock.c
├── Makefile
├── namei.c
├── objectid.c
├── prints.c
├── procfs.c
├── README
├── reiserfs.h
├── resize.c
├── stree.c
├── super.c
├── tail_conversion.c
├── xattr_acl.c
├── xattr.c
├── xattr.h
├── xattr_security.c
├── xattr_trusted.c
└── xattr_user.c

1 directory, 32 files

Как только автор в хату правильно зайдёт ему сразу шконкоместо выдадут.

из тюрячки пишешь?

Над этим работают: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/diff/MAINT...

И потом ещё это ядро с такими вахтёрами и stable API nonsense называют свободным. Под винду драйверы ФС намного проще писать и не надо приходить на поклон Microsoft чтобы их можно было установить.

stable API nonsense

Требование стабильности только к минимальному API, используемом из user space, т.е. системные вызовы. Как раз из-за нестабильности API линукса особо «страдают» проприетарщики, выпускающие драйвера для андроида (а за одно с ними и пользователи).

и не надо приходить на поклон Microsoft чтобы их можно было установить.

Помнится мне, были проблемы с подписью этих драйверов. Даже libusb (libusb0.sys snapshot release and digital signature). Разве можно без регистрации у МС подписать свой драйвер?

Помнится мне, были проблемы с подписью этих драйверов. Даже libusb (libusb0.sys snapshot release and digital signature). Разве можно без регистрации у МС подписать свой драйвер?

Во первых можно запускать драйверы без подписи. Во вторых получить подпись намного проще чем чтобы приняли код в апстрим ядра Линукс.

У нас на работе используются свои ядерные драйвера под Windows для специального железа внутреннего пользования. Представляю какой кошмар был бы поддерживать аналогичные драйвера под Линукс.

Не, ну ты не путай «запустить драйвер под ОС» и «включить драйвер в официальную репу ОС». В мире Виндоус второе возможно только если ты работаешь в МС.

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

Продолжаем терять данные на btrfs? Спаситель задерживается?

В мире Виндоус второе возможно только если ты работаешь в МС.

В мире Windows нет никаких реп и разработчик драйверов может напрямую распрстранять бинарники драйверов и они будут работать у всех ближайшие 15 лет. Нет никакой необходимости включать все драйвера в стандартную поставку ОС. Достаточно зайти на сайт производителей видеокарт например.

Так я и говорю про 4

zfs по другим причинам не в ядре, его бы взяли, если бы могли, да нельзя.

Там всё хуже. Грег КХ сотоварищи регулярно ломает API для ZFS, чтобы тот перестал работать со свежим ядром. Доходило аж до того, что он угрожал в суд на авторов ZFS подать.

Разработчики ядра: «Валите на FreeBSD»

Вообще, разрыв жопы Линуса и Грега по части ZFS порой достигает просто эпических масштабов.

Bcachefs Looks Like It Won’t Make It For Linux 6.6

https://www.phoronix.com/news/Bcachefs-Delayed-Linux-6.6

У Линуса не собралось, как-то так

Kent Overstreet began his latest kernel mailing list post with, «Honestly, though, this process is getting entirely kafkaesque.» After proceeding to air his ongoing frustrations with the Linux kernel upstream process and developer interactions, his latest message ended with, «I’m going to go offline for awhile and think about what I want to do next.»

У нас на работе используются свои ядерные драйвера под Windows для специального железа внутреннего пользования. Представляю какой кошмар был бы поддерживать аналогичные драйвера под Линукс.

А в чём вы видите кошмар? На этом глобусе очень много железа у которого нет дровов «из каробки» в ведре, имхо не так сложно установить|сконпелять модуль по приложенной инструкции.

Нет никакой необходимости включать все драйвера в стандартную поставку ОС. Достаточно зайти на сайт производителей видеокарт например.

О, про видимокарты, а у онтопика не так, что ли?

В мире Windows нет никаких реп и разработчик драйверов может напрямую распрстранять бинарники драйверов и они будут работать у всех ближайшие 15 лет.

Вроде как шинда выпускает релизы почаще, чем раз в 15 лет.

имхо не так сложно установить|сконпелять модуль по приложенной инструкции.

Из-за «stable API nonsense» драйвер может перестать компилироваться/работать в любом следующем релизе ядра. Требуется содержать отдельную команду по поддержке этого драйвера.

О, про видимокарты, а у онтопика не так, что ли?

Разумеется не так. Либо видеодрайверы в составе апстрима ядра и работают нормально, либо «fuck you Nvidia» и ничего нормально не работает, особенно с Wayland.

Вроде как шинда выпускает релизы почаще, чем раз в 15 лет.

В Windows в течение длительного времени сохраняется обратная совместимость драйверов.

Из-за «stable API nonsense» драйвер может перестать компилироваться/работать в любом следующем релизе ядра.

Может да, может и нет, а может это из-за того, что он так криво написан.

Требуется содержать отдельную команду по поддержке этого драйвера.

Такая сложная железка, что целую команду надо держать? Я без подкола.

В Windows в течение длительного времени сохраняется обратная совместимость драйверов.

Длительного только по причине «мы вообще ничего не меняем». И то вспомнил квесты в виде «подбери дровишки, вот для этой железки». У шинды не редкость когда надо подбирать по версиям, последние не факт что рабочие. И вот как дибилоид начинаешь скачивать более старые дрова в поиске какой из них заробит.

А почему ты проводишь примеры на Windows, а не на Haiku? Допустим разработчик захотел предложить туда свой драйвер. Ему будет легче это сделать чем в Linux? А если разработчик не будет соблюдать правила добавления нового кода? Драйвер примут?

А почему ты проводишь примеры на Windows, а не на Haiku? Допустим разработчик захотел предложить туда свой драйвер. Ему будет легче это сделать чем в Linux?

В Haiku есть бинарная совместимость ядерных драйверов и их можно распространять отдельно от ОС. Некоторые драйверы Haiku распространяются в отдельных пакетах вне кодовой базы ОС, например порт Open Sound System (OSS).

Да, и самое прагматичное решение – писать драйвер под конкретную LTS-версию коммерчески поддерживаемого дистрибутива с dkms, а не под абстрактную версию ядра.

Длительного только по причине «мы вообще ничего не меняем». И то вспомнил квесты в виде «подбери дровишки, вот для этой железки».

Это еще повезет, если будет что подбирать! С выходом W10 было достаточно много криков пользователей, что их старые драйвера (например сканеров и принтеров) не работают под W10, а новые никто не пишет, т.к. эти устройства уже не производятся.

Это еще повезет, если будет что подбирать!

Такое тоже возможно.

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

Ну такая же хрень не только под вынью происходила. Однако в целом согласен полностью! Хрень полная! Дорогое железо есть, а дровов нэма, изобретайте лисопед «купите нашего нового слона» дорогие товарищи.

Некоторые драйверы Haiku распространяются в отдельных пакетах вне кодовой базы ОС

Так и в линуксах такое есть. Я имел ввиду непосредственно чтобы в ядро Haiku драйвер влить

А зачем раст в ядре? Почему к примеру не ада и не пл1?

Из-за «stable API nonsense» драйвер может перестать компилироваться/работать в любом следующем релизе ядра.

Может да, может и нет, а может это из-за того, что он так криво написан.

Што? Моя бывшая контора мейнтейнила один модуль для ведра для внутренней кухни, который апстримить смысле не было просто вообще никакого. Из ядер там поддерживались только 2.6.32 и 3.10 (el6 и el7). Так вот, код был раздут где-то на треть из-за ifdef и для разного API между ядрами.

Вы не панимаете, ваше железо нинужно, нужон только реалтек 8139 и другое (принятое в ядро) старье.

Кстати, что характерно, у макоси подобных проблем нет. Лично накатывал драйвер SAS-контроллера, написанный васяном на коленке в бородатые годы и он спокойно работал в предпоследней на тот момент оси без перекомпиляции.

Если ты напишешь драйвер в винде, он не попадёт в официальное ядро. Ставить его надо самостоятельно.

Тебе кто-то запрещает точно так же взять и самостоятельно установить драйвер фс в linux?

Последние 15 лет использую только nvidia. Всё работает. Wayland не использую, так как он не нужен.

Между 2 и 3 это земля и небо. Вы бы ещё 1 привели в пример.

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

В шинде таких проблем нет, за редким исключением (изменение апи видеодрайвера в висте).

Во-первых, апи не так уж часто меняется в плане работы с драйверами. Во вторых, всегда есть LTS-ядра как ванильные, так и дистрибутивные. Нестабильное апи волнует только арчеводов, которые обновляются ради обновлений. В реальной работе всё несколько иначе.

Я имел ввиду непосредственно чтобы в ядро Haiku драйвер влить

Да легко. У человека не работал тачпад в ноутбуке, написал он драйвер, выложил патч в Gerrit (это может любой сделать после свободной регистрации), патч приняли и теперь работает тачпад у всех у кого таже модель устройства.

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

Драйвера тех же EOL видеокарт спокойно работают от vista/7.

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

У супруги на ноуте десяточка. Мой сканер и принтер смотрят на стабильное виндовое апи с удивлением и некоторым непониманием. Проще оказалось подрубить их к домашнему серверу и настроить cups и sane, чем пытаться их завести в оффтопике.

Между 2 и 3 это земля и небо.

Схера ли? 3 изначально должна была иметь версию 2.6.40. Просто Лойнуса задолбали большие числа и он предложил забить на это.

Нифига, это разные линейки, так же как и 1 и 2

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

Да, всего каждый год-полтора. Не весь API, но куча отдельных функций по мелочам таки ломаются.

Во вторых, всегда есть LTS-ядра как ванильные, так и дистрибутивные. Нестабильное апи волнует только арчеводов, которые обновляются ради обновлений. В реальной работе всё несколько иначе.

Да. В реальной жизни разрабы очень большой части железок положили болт на лялекс, потому что мало того, что API постоянно сломан и нужно держать отдельную команду для поддержки, так это ещё и 3% юзеров задевает. Если мы не говорим о серверном железе и не о железе от трёх-четырёх самых жирных вендоров (Intel/AMD/Nvidia), то в лялексе всё довольно тухленько.

Тебе кто-то запрещает точно так же взять и самостоятельно установить драйвер фс в linux?

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

Нифига, это разные линейки, так же как и 1 и 2

И что в них разного? Расскажи же. Чем 3.0 кардинально отличалось от 2.6.39?

Потому что вот тут написано совершенно иное:

As mentioned at the start of the cycle for this kernel, the 3.0 milestone is not about major new features in the Linux kernel. Instead, the version bump was about getting rid of the increasingly large minor version numbers (like “2.6.39.x”) and to acknowledge the kernel’s 20th anniversary this year.

https://www.linuxfoundation.org/blog/blog/its-official-linux-3-0-released

Кому же я верю больше? Linux Foundation или регистранту ЛОРа?

Как минимум конфигурированием. Но до 2.6.39 я емнип не дожил, поэтому могу и соврать.
Плюс всякими «не родными» дровишками, вот это уже было более существенно.

Ничем они не отличаются. Последние глобальные перемены в ядре были между 2.4 и 2.6.