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

Любой человек должен знать два или более языков. В случе IT специалиста знание английского обязательно. Какие могут быть возражения?

Угу, а еще он должен быть добрым, мудрым, и красивым. Непонятно только кому должен.

Хто у нас там звиздел в том самом Documentation(Documentation/stable_api_nonsense.txt) про суперстабильный kernelspace <-> userspace ABI?

The kernel to userspace interface is the one that application programs use, the syscall interface. That interface is _very_ stable over time, and will not break. I have old programs that were built on a pre 0.9something kernel that still work just fine on the latest 2.6 kernel release. This interface is the one that users and application programmers can count on being stable.

Вот-вот, и я о том же...

>Хто у нас там звиздел в том самом Documentation(Documentation/stable_api_nonsense.txt) про суперстабильный kernelspace <-> userspace ABI?

>The kernel to userspace interface is the one that application programs use, the syscall interface. That interface is _very_ stable over time, and will not break. I have old programs that were built on a pre 0.9something kernel that still work just fine on the latest 2.6 kernel release. This interface is the one that users and application programmers can count on being stable.

Он абсолютно прав: то, что стало стабильным, больше уже никогда не меняется, и примером тому являются syscall. Более того, то, что однажды экспортировано в userspace, уже никогда не меняется, только расширяется с обратной совместимостью, что зачастую опять-таки не документируется.

Новые протоколы, например WE over netlink, wconf, sysfs users и т.п. не документированы, и используются каждым так, как он того хочет.

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

Как можно использовать kernel <-> userspace ABI, если оно не экспортировано в юзерспейс? :) Соответсвенно или ABI стабильное или оно нестабильное, третьего не дано, поскольку ABI не может быть частично беременным. Так кто врет - тот кто написал stable_api_nonsense.txt или Грэг?

>Угу, а еще он должен быть добрым, мудрым, и красивым. Непонятно только кому должен.

Прежде всего себе.

> Как можно использовать kernel <-> userspace ABI, если оно не экспортировано в юзерспейс? :) Соответсвенно или ABI стабильное или оно нестабильное, третьего не дано, поскольку ABI не может быть частично беременным.

А теперь начинаем думать.

В ядре создается новый драйвер, который экспортирует некие данные используя sysfs. Драйвер принят в ядро, механизм экспорта передан в userspace, точка поставлена. Драйвер со временем поменялся, и теперь он может передавать данные, используя как старый механизм через sysfs, так и новый, например через netlink. Стабильности здесь, как видишь, нет, но первый интерфейс уже никогда не поменяется.

Или другой вариант из настоящей жизни. Много лет назад был создан WE - wireless extensions via ioctl, все работает как надо. Но со временем wifi эволюционировал, и были добавлены новые версии WE, а со временем появился WE over netlink, причем все версии обратно совместимы друг с другом. Но _стабильного_ WE в целом, т.е. такого, который не меняется, нет и не может быть. Есть стабильные версии с обратной совместимостью, но сам протокол развивается дальше.

Или еще один пример. Для конфигурации wifi стека был написан протокол wconf, с которым работали softmac based карточки, но потом пришел devicescape стек, и протокол был расширен, чтобы поддерживать и новые карточки. Стабильности в том плане, что все заморожено и не развивается, нет. Но есть строгие правила, которых придерживается kernelspace.

>Так кто врет - тот кто написал stable_api_nonsense.txt или Грэг?

Это один и тот же человек.

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

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

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

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

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

Все технически грамотные компании так и делают и прибыль не теряют.

NVidia и ATI очень ограничены лицензионными соглашениями с авторами прошивок GPU и т.п.

Угу. Adaptec - грамотная компания ? Её дровишки под определенное железо входят в состав ядра. Правда, работают они... не дай боже еще раз мне с этой железякой под линухом столкнуться.

PS. Никто не знает железо лучше, чем его разработчики.

>Угу. Adaptec - грамотная компания ? Её дровишки под определенное железо входят в состав ядра. Правда, работают они... не дай боже еще раз мне с этой железякой под линухом столкнуться.

Кривое железо бывает у всех.

>PS. Никто не знает железо лучше, чем его разработчики.

Да, NVidia с ее чипсетом nforce - тоже все было закрыто, а сейчас и в сетевые и в sata драйвера патчи шлют,и даже просят, чтобы включили, т.к. понимают, что есть Linux и кто за ним стоит.

Broadcom - никогда никому спеки не давал, а теперь с удовольствием сетевые драйвера помогает делать на nextreme и tigon чипсетах.

Intel опять-таки.

Те, кто не открывает спецификации в конечном итоге проигрывает, т.к. всегда находится открытая альтернатива.

а зачем вы ставите драйвера ручками и сидите на суперпоследней версии ядра?

Это кривое железо отлично живет на оффтопике.

Во-первых, как же мне быть, если дров для ядра моего дистрибутива нету ? У меня не FC, не RH, не SuSE и не RF.

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