Поддержка ввода/вывода в userspace

ты что, издеваешься? а тред все-еще-висящий-на-первой-странице и имеющий уже 1200 постов про что?

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

Расшифруйте?

> Расшифруйте?

а вот для этого надо или _внимательно_ читать тред на лор, или читать Линуса на lkml.

Может быть, надо так: . "Для широкого класса устройств (но отнюдь не для всех) эти патчи делают компонент драйвера, работающий в режиме ПОЛЬЗОВАТЕЛЯ, тривиальным."

по ссылке не совсем так написано:

> A large number of people have expressed interest recently in the userspace i/o driver core which allows userspace drivers to be written to handle some types of hardware.

и вот это, до кучи:

> So, for anyone that wants to see this go into the tree, now is the time to step forward and post your patches for hardware that this kind of driver interface is needed. If no such drivers appear, then there is a very slim chance that this interface will be accepted into the tree.

> ты что, издеваешься? а тред все-еще-висящий-на-первой-странице и имеющий уже 1200 постов про что?

Про ЭТО :)

И в том же треде мало кто знает, что эти вещи уже доступны. Всё предрекают "смерть от драйвера".

может и про это, но я >1300 постов не осилю. для меня проще в отденльной новости. так что сделай как томи :) и не мешай людЯм читать. :)

+/* + * driver/uio/uio.c + * + * Copyright(C) 2005, Benedikt Spranger <b.spranger@linutronix.de> + * Copyright(C) 2005, Thomas Gleixner <tglx@linutronix.de> + * Copyright(C) 2006, Hans J. Koch <hjk@linutronix.de> + * Copyright(C) 2006, Greg Kroah-Hartman <greg@kroah.com> + * + * Userspace IO + * + * Base Functions + * + * Licensed under the GPLv2 only. + */

Круто! :)))

> Круто! :)))

> Licensed under the GPLv2 only.

? :)

Именно так ;)

Давно пора

А про безопасность уже кто нибудь подумал?

Кстати, ребят: firefox2.0 + firebug 1.0 rc4 ctrl_enter is not defined (для каждого символа который я ввел - т.е. уже 200 ошибок)

> Может быть, надо так: . "Для широкого класса устройств (но отнюдь не для всех) эти патчи делают компонент драйвера, работающий в режиме ПОЛЬЗОВАТЕЛЯ, тривиальным."

Нет, так не надо. Тривиальным становится именно компонент режима ядра, в этом вся соль. Если объяснять кратко: единственной принципиальной трудностью userspace-драйверов является то, что на одном IRQ может висеть несколько устройств. Пример: когда приходит прерывание, ядро вызывает обработчики данного IRQ до тех пор, пока какой-то из них не скажет "это мое прерывание" и "успокоит" устройство (сделает с ним что-то, после чего оно снимет запрос прерывания). Вот это действие как раз и невозможно (точнее, трудно до непрактичности) реализовать в userspace: например, драйвер окажется в свопе, а на опрашиваемом IRQ висит и драйвер диска (мгновнное зависание). Interrupt latency неизбежно будет высокой (потому что переход в режим пользователя и обратно), причем для всех устройств на данном IRQ (в худшем случае). Однако _кроме_ этой проблемы с IRQ, принципиальных ограничений на существование userspace-драйверов нет. Так вот, патчи из новости как раз и предоставляют всю инфраструктуру для того, чтобы написать весь userspace-драйвер, _кроме_ обработчика IRQ - обработчик должен быть в ядре. Но обработчик IRQ - вещь несложная, поэтому я и написал в новости, что компонент режима ядра тривиален.

Почему "для широкого класса устройств (но не для всех)" - насколько я понял из патчей и их обсуждения, таким образом (пока что?) нельзя реализовать устройство, доступ к которому одновременно осуществляют несколько процессов (не говоря уже о блочном или сетевом устройстве). Кроме того, поддерживается только 1 регион памяти.

[Могу ошибаться, но не предусмотрено даже создание спецфайла для устройства. Таким образом, uio - это скорее фундамент для библиотеки доступа к устройствам из userspace ]

> может и про это

не про это - там народ в основном идеологическими спорами занимается: выясняет границы свободы в применении к программно-аппаратным комплексам 8)

> но я >1300 постов не осилю

...хотя мы с rtc там поспорили и о usercpace-драйверах тоже 8)

В письме же написано, что для того что бы ... UIO включили в ядро ... нужны РЕАЛЬНЫЕ драйверы. Без них вся эта технология никому не нужна. Вопрос, на сколько консервативны разработчики драверов. :)

А нафига оно надо тем, кто разрабатывает GPL дрова?

Только если проприетарщики или Novell подсуетятся.

> А нафига оно надо тем, кто разрабатывает GPL дрова?

Поразрабатывай драйверы - поймешь, что в userspace программы отлаживать _гораздо_ легче.

> Только если проприетарщики или Novell подсуетятся.

Будем надеятся

>Поразрабатывай драйверы - поймешь, что в userspace программы отлаживать _гораздо_ легче.

Поразрабатывал. Как я понимаю, в данном случае вероятность уронить систему не становится существенно меньше.

Только если работа с памятью.

>> Поразрабатывай драйверы - поймешь, что в userspace программы отлаживать _гораздо_ легче.

>Поразрабатывал. Как я понимаю, в данном случае вероятность уронить систему не становится существенно меньше.

> Только если работа с памятью.

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

Кстати, спасибо.. Любопытненько.. А то, первого мегатреда не читал.. Да и не собираюсь..

>ошибки с памятью стали безопасными - уже очень большой плюс.

Ну да, наверное.

>при условии, что обработчик IRQ написан правильно

Как мне кажется, неправильная работа с железкой может убить систему на аппаратном уровне (записать не то/не в тот порт).

Всё-таки это пока ещё не микроядерный подход. Хотя направление верное.

Ещё мне кажется, что оверхед будет довольно большой. Для драйвера какой-нибудь не сверхбыстрой ленты ещё сойдёт. Но видео с его огромными потоками данных вряд ли будет работать нормально.

>>при условии, что обработчик IRQ написан правильно

>Как мне кажется, неправильная работа с железкой может убить систему на аппаратном уровне

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

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

Ну, если учесть, что DMA пока не поддерживается (если я правильно понял) - то конечно. Но лиха беда начало...

Да здравыствует микроядерный Линукс?

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

Лучше макроядро - будет макроядро.

Понадобились фичи микроядра - fuse, UIO.

Ну увидем, приживется или нет, но это покажет только практика :)

>Понадобились фичи микроядра - fuse, UIO.

Ты прав, но от этого Линух не станет микроядром... А что тогда толку от такого смешенного подхода?

/me представил себе драйвер гигабитного адаптера в userspace :)

> /me представил себе драйвер гигабитного адаптера в userspace :)

Уж сколько раз я постил эту ссылку 8) http://www.linuxsymposium.org/proceedings/reprints/Reprint-Chubb-OLS2004.pdf

Гигабитный, в userspace, и быстрее ядерного :-P

ДЫк в том мегатреде rtc обратное утверждал.

Правда я только просмотрел, может не так понял?

Ну, скажем так - он меня не убедил. Кроме того, там дискуссия сфокусировалась на userspace IDE драйвере, который и в самом деле медленнее ядерного, и теоретически, хуже масштабировался. Но userspace Gigabit Ethernet в чем-то даже быстрее, чем ядерный.

Правда, к топику это имеет только косвенное отношение - в текущей реализации uio не поддерживается DMA, да и судьба всего фреймворка неясна :/

> Для драйвера какой-нибудь не сверхбыстрой ленты ещё сойдёт. Но видео с его огромными потоками данных вряд ли будет работать нормально.

а DRI как работает? ведь пускает напрямую к видяхе

>Уж сколько раз я постил эту ссылку 8)

Спасибо, покурил, любопытно... Кста, а что такое memory mapped io? Это какая-то фича PCI? Если я правильно понял, это отображение портов в пространство памяти, позволяющее делать mov вместо in/out?

объясните пожалуйста почему под линуксом не ставятся драйвера как под виндой? например чтобы прочитать ext3/ext2 разделы есть драйвера - ставишь и нет проблем, а вот чтобы добавить поддрержку ntfs уже в линуксе нужно кажется добавлять в ядро его поддержку и компилировать или чето в нем извенить и загружать как модуль кажется - опятьже все компилируя. И так я понимаю с любыми дровами. Что это за напасть такая или подход - хотябы в двух строчках или где почитать подрбно по поводу этих разных подходов подскажите.

>объясните пожалуйста почему под линуксом не ставятся драйвера как под виндой? например чтобы прочитать ext3/ext2 разделы есть драйвера - ставишь и нет проблем, а вот чтобы добавить поддрержку ntfs уже в линуксе нужно кажется добавлять в ядро его поддержку и компилировать или чето в нем извенить и загружать как модуль кажется - опятьже все компилируя. И так я понимаю с любыми дровами. Что это за напасть такая или подход - хотябы в двух строчках или где почитать подрбно по поводу этих разных подходов подскажите.

Ты всё перепутал ;) Под linux также можно брать и ставить бинарные дрова, которые за тебя скомпилял вендор (многие производители железа таки и делают как например NVIDIA) или автор дистрибутива. НО удобнее распространять драйвера для линукс именно в виде исходников особенно это важно для разработчиков. Дело в том что _различные_ версии ядра windows можно посчитать с помощь пальцев одной руки а версий ядра линукс _сотни_ (в том числе и параллельные ветки от крупных дистрибуторов типа RH или SuSE) и оно постоянно меняется. Понятно что сотен версий драйверов не нужно но десятки запросто.

>Ты всё перепутал ;)

А по-моему это был тролль...

>объясните пожалуйста почему под линуксом не ставятся драйвера как под виндой?

Ставятся.

>например чтобы прочитать ext3/ext2 разделы есть драйвера - ставишь и нет проблем, а вот чтобы добавить поддрержку ntfs уже в линуксе нужно кажется добавлять в ядро его поддержку и компилировать или чето в нем извенить и загружать как модуль кажется - опятьже все компилируя.

Кажется - очень плохое слово, которое не извИняет незнание.

Ядер много. Дистрибутивов много. Под стандартное дистрибутивное ядро той же fedora есть отдельные уже собранные драйверы под ntfs, nvidia и т.п.

Под виндой ядер прямо скажем не разнообразие. Их тоже собирают - ты не поверишь, даже исходники дают на тот же ext2/ext3 - но из-за отстутствия разнообразия распространить их полегче. Плюс у виндов не меняется модульное API - они не улучшают систему (а в линуксе, как сказал Линус, "мы исправляем фундаментальные баги").

>И так я понимаю с любыми дровами. Что это за напасть такая или подход - хотябы в двух строчках или где почитать подрбно по поводу этих разных подходов подскажите.

Даже читать особо ничего не нужно - простая логика.

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

господам нехило бы почитать вот это:
http://www.gossamer-threads.com/lists/linux/kernel/715550

мр торвальдс например говотир НАХ!

<quote>

Ok, what kind of ass-hat idiotic thing is this?

irqreturn_t uio_irq_handler(int irq, void *dev_id)
{
return IRQ_HANDLED;
}

exactly what is the point here? No way will I pull this kind of crap. You
just seem to have guaranteed a dead machine if the irq is level-triggered,
since it will keep on happening forever.

Please remove.

YOU CANNOT DO IRQ'S BY LETTING USER SPACE SORT IT OUT!

It's really that easy. The irq handler has to be _entirely_ in kernel
space. No user-space ass-hattery here.

And I don't care one whit if it happens to work on parport with an old
legacy ISA interrupt that is edge-triggered. That's not even the
interesting case. Never will be.

NAK NAK NAK NAK.
</quote>


p.s.

если кто не догнал, то NAK NAK NAK NAK - означает НАХ НАХ НАХ

Специально для мастеров перевода, которые не читали Documentation/ManagementStyle:

<quote> You're clearly not competent to make that decision for them. ... and there back-tracking is very easy: just tell everybody that you were an incompetent nincompoop ... You should always reserve the right to change your mind, and make people very _aware_ of that. </quote>

> например чтобы прочитать ext3/ext2 разделы есть драйвера - ставишь и нет проблем, а вот чтобы добавить поддрержку ntfs

хреновый пример. Формат ext3/ext2 полностью открыт, а ntfs afaik закрыт.

> объясните пожалуйста почему под линуксом не ставятся драйвера как под виндой? например чтобы прочитать ext3/ext2 разделы есть драйвера - ставишь и нет проблем, а вот чтобы добавить поддрержку ntfs уже в линуксе нужно кажется добавлять в ядро его поддержку и компилировать или чето в нем извенить и загружать как модуль кажется - опятьже все компилируя.

Поставь ntfs-3g, который работает в userspace и умеет работать с NTFS в режиме R/W и не ипи моск.