Скорость изменения Kernel API и почему его нельзя сделать более стабильным

https://lkml.org/lkml/2016/4/6/646

Если вы не согласны с этим, это нормально, вы можете форк ядро в любой конкретной точке и сохранить этот API стабильным, так же , как многие компании делают и делать деньги из него (SuSE, Red Hat и т.д.)

лучшие удачи с вашим проектом ядра,

Greg KH

Как жестоко :(

вывод: форкай и будет тебе счастье

Меня интересует техническая сторона вопроса. Почему нестабильное API выгоднее стабильного? Ведь в самом ядре полно модулей, которые используют это же API. И охота им править все модули каждый раз? А ведь модулей становится всё больше и больше.

ТС спалился?

Не знаю насчёт ТС'а, но там в рассылку писал бирди

На дату не посмотрел.

Что ты понимаешь под стабильностью? Какая степень стабильности тебе нужна?

Грег как раз и пишет, что они не ломают особо, стараются. Но совсем без изменений то нельзя. И то они очень аккуратные.

Если же нужно прям совсем без изменений, форкаешь ядро и замораживаешь код.

офигеть аргументация: «если вам не нравится наша ОС — ваши аргументы не аргументы, потому что мой сосед вообще жену бьёт»

Я, как программист (хоть и не кернел девелопер) вижу три причины

1. Изменение самих устройств
2. Осознание того, что API был реально плохо спроектирован
3. NIH-синдром

Первые две технические, третья - неотъемлимая часть OpenSource

Осознание того, что API был реально плохо спроектирован
NIH-синдром

Ещё монолитное ядро.
Надо было микроядерную архитектуру делать. Ну разве мог финский студент это понимать?

Ну мне подход в линукс ядре нравится. Поскольку опыт поддержки мохнатых лохматых библиотек у меня тоже есть. И это не самое приятное в жизни. Когда подпорок к коду больше самого кода и все ради стабильности

Ещё монолитное ядро.
Надо было микроядерную архитектуру делать.

Это туда же, в пункт 2 к плохому api.

Ну разве мог финский студент это понимать?

А какая архитектура у BSD, MacOS и Win? Что-то я не вижу успешных микроядер.

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

У них там разрабов дофига.

Грег как раз и пишет, что они не ломают особо, стараются.

Они не ломают, они выкидывают.

И охота им править все модули каждый раз?

Я вроде читал, что у них определённые требования к оформлениям исходников ядра, позволяющие им обновлять код под изменённый api чуть ли не перловым скриптом.

Что-то я не вижу успешных микроядер.

symbian был довольно успешен

И тут пришёл злобный линукс в лице андроида? ))

прочитай уже Documentation/stable_api_nonsense.txt и все сразу станет понятно

symbian был довольно успешен

Нет такого понятия как «был успешен». Раз закопали, значит fail.

Каким образом микроядерная архитектура повлияет на стабильность API? API это соглашение по взаимодействию некоторых кодов друг с другом. То в ядре они или не в ядре никакой роли не играет. Если ваш любимый, скажем драйвер блочного устройства, сделанный в виде пользовательского процесса поменяет api из-за расширения возможностей, исправления ошибок в дизайне или чего угодно, но вы в своём драйвере fs(также работающем как пользовательский процесс), который зависит от блочного драйвера ничего не измените, разве ничего не сломается?

С какой скоростью изменяется API ядра Linux для модулей?

Не так и быстро изменяется, но так как чаще всего нужна поддержка начиная с какого-нибудь 2.6.18 и заканчивая master, то очень просто превратить исходники в мешанину из #ifdef. Но это зависит от степени интеграции в ядро — чем она ниже, тем меньше проблем.

Есть ли практические причины, по которым нельзя сделать хотя бы для определённых модулей более-менее стабильный API?

Иногда разработчикам ядра непонятно что вообще есть API для модулей, а что нет. В итоге модуль не собирается, а потом находишь коммит в стиле «Эту функцию все равно никто не использует, и я не знаю зачем она кому-то может быть нужна. Поэтому давайте ее выпилим!».

Почему нестабильное API выгоднее стабильного?

Дешевле. Проще поменять функцию и десяток мест, где она вызывается, чем поддерживать годами пяток версий этой функции, работающих и вызывающихся по-разному. В ядре регулярно бывают коммиты вида «мы поменяли функцию X на функцию Y всюду, где она вызывалась». Причем часто это делают люди, совершенно незнакомые с модулями, где вызывается X/Y, но детально знающие сами функции X/Y. Внутри ядра ломают всё и всегда, все драйвера приходится из-за этого активно поддерживать, чем и я сам занимался несколько лет.

Но API для пользовательских программ - неизменен, только обрастает новыми системными вызовами со временем. Точка зрения Линуса - этот API ломать нельзя. Только разработчики библиотек так не считают...

нет тут пришел злобный microsoft и закопал nokia

так закопали его микрософты, они известные мастера покупать и закапывать

На самом деле я слышал о гнилых внутренностях симбиана и о том, что это dead end и что под него писать — жуть и вообще, хорошо что сгинул. Хотя сам писал под нокловские телефоны в то время на qt иничо. Но я во внутренности не лазил.

почему его нельзя сделать более стабильным

По секрету: в любом живом и развивающемся проекте, хоть что-то из себя представляющем, внутренний API ломается регулярно, но этого никто особо не замечает, т.к. любая нормальная IDE рефакторит миллионы строк кода за неск.секунд или же очень способствует этому (в зависимости от конкретной ситуации).

Какова вероятность того, что

Вероятность не равна нулю.

Нука нука, в какой нормальной ide разрабатывается код ядра?

Не писал под symbian, но помоему гуюгл сделал все что-бы под их телефон приложения могла написать любая web-макака, потому и имеет кучу шлака в их app store, под symbian софта было заметно меньше, но он был качественнее. Хотя может во внутренностях действительно бардак творился, они до ms тоже рассматривали варианты перехода на linux и ведроид.

лучшие удачи с вашим проектом ядра,

Надмозг!

Любой ответ будет неправильный, т.к. у тысяч разрабов тысячи ответов на этот вопрос.

Почему это, думаю, эта ссылка уже visited? ;)

Фу таким быть.

Вы не умеете в сарказм?

p.s. Гуглите на тему срача Торвальдса с Таненбаумом «Монолитное ядро vs микроядро»

Ух ты, Бирди уже ноет и в lkml.

В тему пришлась :-)

лучшие удачи с вашим проектом ядра,

Лак товарищ!

Почему на уровне исходного кода совместимость практически нулевая?

Потому что дефекты API зачастую следует править путём жестокого беспощадного рефакторинга всех, кто к этому API имел какое-либо отношение. Не тащить за собой кишащий тараканами ворох пережитков прошлого.

Почему на уровне исходного кода совместимость практически нулевая?

Почему ты лжешь?

Ой, я имел в виду бинарного кода. Но с исходным тоже проблемы. Собственно, мой вопрос был, как часто ломают. Вот, например, патчи для broadcom wl: https://aur.archlinux.org/packages/broadcom-wl-dkms/ Сначала пропатчили под 4.7, а потом пришлось патчить под 4.8.

Почему на уровне исходного кода совместимость практически нулевая?

Почему ты лжешь?

Ой, я имел в виду бинарного кода.

Не юли. Ты написал «исходного», потому что это и хотел написать.

Почему на уровне исходного кода совместимость практически нулевая? Как я понимаю, намного хуже, чем на бинарном.

и в lkml.

И в багзилле ядра, и ещё статейки пишет. Зря времени не теряет. А его обзорные статьи типа «как всё плохо 2016» даже очень полезны. Это фактически сборник всего того, что нужно в линуксах чинить. Туда удобно направлять тех, что хочет что-то сделать, но внятно свою хотелку сформулировать не может.

Есть ли практические причины, по которым нельзя сделать хотя бы для определённых модулей более-менее стабильный API?

Это будет ад из 3rd-party модулей. А сейчас все широкоиспользуемые драйвера так или иначе пропихиваются в ядро.

Туда удобно направлять тех, что хочет что-то сделать, но внятно свою хотелку сформулировать не может.

Ну разве что «удобно». Потому что проблемы, о которых ноет бирди - они сложные, и те, кто не может даже сформулировать хотелку, их не решат.

Я ошибся. Уже засыпал в тот момент, когда писал. Поэтому и перепутал слова местами.

Проприетарные не пропихнуть. Поэтому для проприетарщиков он является только основой для проприетарных необновляемых прошивок.

и те, кто не может даже сформулировать хотелку, их не решат.

Дык, если бы они могли их решать, проблем бы уже не было!

Проприетарные не пропихнуть

О чем и речь. Многоходовочка!

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

Точку зрения Таненбаума можно поддерживать из академической чистоты и научности. На практике же, на производстве лидирует пока то, что мы видим сейчас. Из-за нереальной сложности микро-ядра, неоправданной экономически.