Статистика удаления поддержки оборудования из ядра.

Драйверы разные бывают... Некоторые с нуля переписываются каждый мажорный релиз типа 2.6.35, 3.0, 3.2, 3.4, 3.8...

удаления поддержки оборудования из ядра

А что вообще значит поддержка оборудования в ядре? Это же единожды написанный кусок кода в виде отдельного модуля. Хай себе лежит никого не трогает, есть не просит. Поддержа - это попахивает проприетарщиной, а здесь жпл. Хочешь вноси изменения в код, если ума хватит, хочешь не вноси.

Он наверное вспомнил недавнее выпиливание поддержки старых процессоров.

Также интересует вопрос: у Microsoft для вендодрайверов нет ли случайно какой-либо программы, когда производитель передаёт им исходный код, а они сами поддерживают драйвер в актуальном состоянии?

Одни проприетарщники добровольно передают свой говнокод другим для дальнейшей поддержки? Я б на месте MS за такое извращение столько б профита попросил...

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

Пример того, что давно нужно выпилить - 3C501 (версия драйвера 2002 года), это ISA-шная 8bit ethernet card ( да еще и без памяти). Они вымерли сразу после появления 3C509C.

Про XT hard disk controller та же история.... Где сейчас эти диски конца 80-х ?

Обычно дрейвер долго маринуется, потом, когда выясняется, что он уже стал неработоспособным

Ну а как часто бывает, что драйвер есть, но он перестал быть работоспособен (а на старых ядрах работал)?

Про stable api is nonsence слышал? Так вот, от версии к версии в API ядра могут вноситься изменения, приводящие к несовместимости с новыми модулями. Это не специфика Linux, в Windows тоже такое есть. Однако, как я понимаю, там определённости больше. В рамках одного выпуска вряд ли можно ожидать поломки, но M$ и не на это способны. В случае с Linux же твой драйвер может не заработать в каждой следующей версии.

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

но M$ и не на это способны

У тебя предвpятость из ушей капает. Эти упороши до сих пор обратную совместимость тащат для 9x.

Эти упороши до сих пор обратную совместимость тащат для 9x.

Для kernel-драйверов?

Эти упороши до сих пор обратную совместимость тащат для 9x.

Напейся из дуршлага... э-э-э в смысле, запусти а) любой неподписанный драйвер; б) любой драйвер, вносящий модификации во внутренние структуры ядра на 64-битной винде.

Ты сейчас сравнил ядра окошек и linux.

У многих до сих пор предвзятое отношение к «64-битной винде». Но это тема для отдельного разговора.

Что я не так сравил?

Напейся из дуршлага...

Да поможет ему Его Макаронейшество в этом!

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

то есть, для начала, из-за изменений api, ядро, имеющее в своем составе данный драйвер, перестает собираться?

нет, не часто, потому как устройств уже нет и об этом уже никто не может узнать :)

ну конкретно драйвер я не назову, а вот почему оно может перестать работать могу пояснить.

За последние 10 лет была существенно переделана система выделения памяти в ядре. Старый драйвер попросивший памяти во время прерывания без доп. флагов (их тогда небыло) может ее не получить.

Таких «граблей» еще можно найти.

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