В ядро Linux 2.6.23 включен стабильный Userspace Driver API

> У меня вопрос ни кто не знает какого нибудь демона использующего /dev/input/event ,я перерыл весь portage ни чего не нашел.

иксам можно указать использовать /dev/input/event. А если ещё и использовать драйвер evdev, то вообще можно делать что угодно.

Так а в чем проблема с /dev/input/event? По-мойму evdev драйвер как-раз для таких случав и был написан:)

Опередил:)

kmike А я на самом деле испытывал трудности только с ЮСБ усройствами по сей день... А "тормознутость", подключая какой-нить йаТелефон или ипак - некритичен...На видяху драва же на нем не собираются писать...

Миникскапец?

Кстати, у меня такая мысля возникла:

К всякому электронному мусору вроде планшетов и фотиков практически в обязательном порядке кроме дров под винду кладут дрова под макось. Есть ли обвязки, позволяющие использовать эти дрова в линухах и насколько будет сложно написать такую обвязку? Ядро-то теперь у макоси открытое ;)

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

хм... и увидел демон что это хорошо и сказал "да будет так"... и стало так...

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

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

> Я давно кстати говорю - жабамашину в биос, кернел на жабе, а окружение на пыхе - и будет всем счастье!

Это не новость. Были проекты и покруче: проект Java-on-Chip у Сана предполагал аппаратную (!!!) реализацию JVM, однако был заброшен. Сейчас Вашу идею реализовать абсолютно ничего не стоит, и, я думаю, подобные изделия уже имеются, только не в массовом масштабе.

ОДНАКО... в БИОСе из интерпретируемых систем проще реализовать не Яву, а Форт: так сделано на всех спарковских машинах у Сана. Обновление Форт-системы в ПППЗУ несопоставимо проще, чем обновление Явы: переопределил нужные слова и дал команду на запись... Яву можно навесить СЛЕДУЮЩИМ уровнем, загружая ее через стандартный путь загрузки.

На самом деле тенденция идет именно к переписыванию все больших частей системы на интерпретируемом коде. Вот вам Виста: на сыром в смысле производительности дотнете переписали весь графический интерфейс!!! Кошмар!!! JDS у Сана хоть как-то поворачивается на шустрой Яве, а тут...

> Линус Торвальдс включил в основную ветку ядра патчи, реализующие driver in userspace API в Linux. > Стабильный драйвер API уже анонсирован год назад. Теперь последние патчи и API включили в дерево Linux. Идея API - сделать проще разработку драйверов:"Этот интерфейс дает возможность написания большинства драйверов в userspace, с очень маленькой оболочкой драйвера внутри ядра. > В API используется char device и sysfs для взаимодействия с userspace процессом, прерываний процесса и доступом к памяти"

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

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

Должно быть примерно так:

> Линус Торвальдс включил в основную ветку ядра исправления, реализующие интерфейс API для драйверов в пользовательском пространстве (вариант: пользовательской области). Стабильный интерфейс API для драйверов уже анонсирован год назад Грегом Кроа-Хартманом. Теперь последние исправления выгружены, и интерфейс API включен в дерево Linux. Идея интерфейса API - упростить жизнь разработчикам драйверов: "Этот интерфейс дает возможность написать большую часть кода драйвера в пользовательском пространстве, при этом собственно в ядре будет находиться очень маленькая оболочка драйвера. Эта оболочка использует символьное устройство и sysfs для взаимодействия с процессом в пользовательском пространстве для обработки прерываний и контроля за доступом к памяти."

Есть разница???

Конечно, разница есть. Во всяком случае, зубодробительное сочетание "интерфейс API" в первом варианте не используется.

ЗЫ Наверное, по сути второй вариант правильней - но если боретесь за правильность передачи семантики, не забывайте о простейших правилах великого и могучего.

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

Уж "возможность написания большинства драйверов в userspace" и "возможность написать большую часть кода драйвера в пользовательском пространстве" точно отличаются, именно по сути

> ну-ну... дарвин микроядерный только номинально - поверх мача крутится единственный процесс

Не совисием корректно сказано: BSD и весь IOKit крутятся в одном большом адресном пространстве, и никак не используют микроядерность OS X/Mach-а для изоляции различных подсистем друг от друга. С другой стороны, общение между userspace-ом и дровами писанными на IOKit-е происходит через mach ipc (об этом косвенно свидетельствует то, что для того, что-бы "пообщаццо", нужно получить обьект типа mach_port_t для того или иного IOService).

> К всякому электронному мусору вроде планшетов и фотиков практически в обязательном порядке кроме дров под винду кладут дрова под макось. Есть ли обвязки, позволяющие использовать эти дрова в линухах и насколько будет сложно написать такую обвязку? Ядро-то теперь у макоси открытое ;)

У OS X, на сколько я знаю, далеко не весь IOKit открыт, а без него дрова, на его основе писанные, не заработают.

и когда же reiser4 включат в ядро...

>недавно покупал вебкамеру, так прям на коробке написано "Linux compatible" или чёто-такое

А что за модель?

2.6.23 - мегаверсия :)

Дык была новость, был эксперимент :) правда он не нашёл пока продолжения. Но всё впереди :D мощности процессоров растут ;)

А просядет ли она? Роберт Лав пишет, что время между процессами распределяется достаточно хорошо. Будем надеятся, что хоть отложенные прерывания перенесут в юзерспейс. Хотя проблемы всё равно будут. Пол драйвера в ядре, пол драйвера юзерспейсе :D

minix3 forever!

Да я не спорю. Но мне жестко резануло глаза вышеозначенное словосочетание.

В общем новость до конца то не раскрыта. Всё ради чего было сделано:

http://liquidat.wordpress.com/2007/07/21/linux-kernel-2623-to-have-stable-use...

The background motivation for the inclusion of such a stable API comes form the embedded world: there embedded drivers are often closed source and just developed for a single kernel version and are not maintained over time. Using the new API these drivers could be used for a longer time. And in fact such an API has already been developed by people from the embedded industry to make their life easier. But it was just developed for a single device and not as a generic interface. Such developments are now unnecessary.

However, DMA transfer between userspace and kernelspace is not yet implemented. This means essentially that drivers which involve high traffic are not an option yet. So graphic drivers as well as file system drivers and similar cannot use this API at the moment.

В общем тема известна: берём одну платку рс/104, берём другую платку рс/104. Разумеется драйвера будут под разные версии ядра не совместивые между собой. Драйвер userspace решает проблему совместимости. Но чегото мне кажется что будет он популярен для usb устройств и подобных ему интерфейсов.

Опа! Может сбудется моя мечта, чтобы не нужно было искать драйвера для каждой конкретной версии ядра! Чтобы был просто драйвер для ядра 2.6, а не для 2.6.20, уже не работающий с более новым 2.6.21!

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

> Во всяком случае, зубодробительное сочетание "интерфейс API" в первом варианте не используется.

Придумано это словосочетание специалистами по локализации из Микрософта и Хулетта по одной простой причине: сокращение "API", выполняющее функциональную роль существительного, не может иметь грамматической формы, так что необходимо дополнительное слово-носитель грамматической формы (т.е. имеющее число и склоняющееся). Далее просто деваться некуда. В тех случаях, когда носитель грамматической формы забывают, получаются совершенно кошмарные результаты, по крайней мере в тяжеловесных технических текстах Микрософта, перенасыщенных сокращениями выше всяческой меры. Почитайте ранние (до 2005 года) русскоязычные материалы в MSDN. Когда я впервые их увидел, чуть не поседел: слэнг дурного игрового клуба в глухом Подмосковье...

Торвальдс - реанкарнация БГ 21 века :D

Я понимаю о чем Вы говорите, но нельзя ж так над языком издеваться. Давайте введем Содружество СНГ (или еще интереснее Содружество НГ, привет Новому Году), Штаты США, Организацию ООН (Организацию UNO?), Союз EU (или Союз E?) и др. интересные сочетания.

Я лично гораздо лучше думаю о БГ. Тем более сам БГ пользует мак, если верить одной известной фотографии...

> Давайте введем Содружество СНГ

Микрософто-хьюлеттовская инициатива относится ТОЛЬКО К ИНОЯЗЫЧНЫМ СОКРАЩЕНИЯМ. Насчет этого примера: есть еще британское Содружество Наций (английский аналог СНГ). Кроме того, сколько на свете СНГ, а сколько интерфейсов API???

Примеры политического характера здесь вообще неуместны. Со времен царя Ивана Грозного, а потом с некоторым перерывом с 1920-х годов иноязычные политические термины переводятся полностью (за редчайшим исключением) или по крайней мере транслитерируются (например, ЮНИСЕФ) и используются по особым правилам "казенного" языка. К технике эти правила не относятся.

Резон микрософтовского предложения состоит в том, что иноязычная нетранслитерированная аббревиатура выступает как неделимый и неинтерпретируемый элемент целевого языка, "имя собственное", если угодно. По крайней мере, такая трактовка явно присутствует в микрософтовском Руководстве по стилю перевода, но самой же языковой группой Микрософта (MILS) она выполняется непоследовательно.

Ваша интерпретация носит слэнговый характер и допустима в УСТНОЙ речи профессионалов, но не в официальных документах. Я, как и все, позволяю себе в устной речи выражения типа "LDAPовский сервер" и, естественно, употребляю сокращение "API" без слова-носителя грамматической формы, но в документе это категорически недопустимо.

Помимо всего прочего, некоторые (например, Микрософт, но не только) любят без лишних церемоний менять расшифровки общепринятых аббревиатур. Типичный пример - DNS. Изначально (в 1980-х) это Domain Name Service, потом в документах у Микрософта это сокращение по-тихому стало интерпретироваться как Domain Name System, и одновременно появились чудовищные агрегаты типа DNS Name и, что хуже всего, русские интерпретации типа "DNS-имя" (вместо "доменное имя").

> русские буквы такого-же цвета что и латинские - иногда путает.

Так на клавиатуру смотреть не надо, надо на монитор смотреть :)

> Штаты США

Регулярно вижу в СМИ :)

>русские буквы такого-же цвета что и латинские

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

+ потдержка железа улучшиться - безопасность ухудшиться