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

вы им скажите чтоб по русски сразу писали, а не на своем буржуинском, а то чтож потом 1/6 части суши мучаться с переводом :)

Не надо на русском, вы чего?! Сейчас большинство ЛОРа вас камнями закидают и заставить учить великий и могучий английский :) И будут доказывать, что без знания оного вы никто и звать вас - никак :)

Доминировать будет тот язык, за которым технологический прогресс. (И ещё тот, у которых денег больше, вот. :))

Привет от братьев китайцев ;-)

не допустим к доке лоббистов от 1C ! :-)

китайцы нам такие же братья как крысы или тараканы

Это правильная идея. Может быть благодаря этому линукс и перерастёт во что-нибудь модульное (модульное употреблено в контексте "не монолитное").

> Сейчас большинство ЛОРа вас камнями закидают и заставить учить великий и могучий английский :) И будут доказывать, что без знания оного вы никто и звать вас - никак

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

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

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

> Greg Kroah-Hartman предложил документировать kernelspace <-> userspace ABI для каждого ядра, даже если эти механизмы взаимодействия часто меняются. Для этого предложено описывать их в stable, unstable, testing и т.п. директориях в Documentation/.

Хто у нас там звиздел в том самом 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.

> китайцы нам такие же братья как крысы или тараканы

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

>>Greg Kroah-Hartman предложил документировать kernelspace <-> userspace ABI для каждого ядра, даже если эти механизмы взаимодействия часто меняются. Для этого предложено описывать их в stable, unstable, testing и т.п. директориях в Documentation/.

>Хто у нас там звиздел в том самом 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 или Грэг?

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

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

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

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

> Как можно использовать 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.

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