Вот только того - кому можно вопросы задавать нет.

А-а-а-а-а-а ... ... ... ;)

Известная история:

... я такая красивая, а он меня бросил ...

И губки надули... ;)

> А у монолитного ядра нет достоинств, вот потому, собственно, и «забыл»(с).

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

А в Linux-е есть такая вещь как User-space device drivers:
раз - http://lwn.net/Articles/66829/
два - http://lwn.net/Articles/232575/
Вот только никому что-то драйвера в юзерспейсе особо не сдались.

Слишком толсто, даже для ЛОРа.

Вам тоже понравилось? ;)

Вот только никому что-то драйвера в юзерспейсе особо не сдались.

В значительной мере - да. Но вот все драйвера видео X11 - они все в юзерспейс (ну, ... за исключением уж совершенно проприетарных, типа NVIDIA).

А в Linux-е есть такая вещь как User-space device drivers:

я знаю ;)

(хотя главная «вкусность» не в юзерспейс драйверах)

раз - http://lwn.net/Articles/66829/ два - http://lwn.net/Articles/232575/

а за ссылки спасибо, почитаю (только годы там ... 2004, ну, 2007, от силы ;))

>В значительной мере - да. Но вот все драйвера видео X11 - они все в юзерспейс (ну, ... за исключением уж совершенно проприетарных, типа NVIDIA).

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

Вообще на LWN только обзорные статьи.
Надо смотреть в kernel-doc, там наиболее актуальная информация: http://kernel.org/doc/htmldocs/uio-howto.html

> Да и скорость в непривелегированном режиме меньше должна быть

Это с какой стати?

Книжка интересная. Но её ещё не касалась рука редактора. Не по-русски она написана. От гугло-промтизмов «Архив кодов примеров», «Такой способ взаимодействия с модулем может полностью заменить средства вызова ioctl() для устройств, который устаревший и считается опасным.» etc, режет и глаз и мозг.

Большое спасибо

Действительно, очень интересно.

Книжка интересная. Но её ещё не касалась рука редактора.

Это вы угадали. Её действительно не касалась рука редактора - пока только разговоры с редактором ведём о редактировании. Пока это - конспект, который писался себе для занятий, чтобы подглядывать.

Не по-русски она написана. От гугло-промтизмов «Архив кодов примеров», «Такой способ взаимодействия с модулем может полностью заменить средства вызова ioctl() для устройств, который устаревший и считается опасным.» etc, режет и глаз и мозг.

Ну так вы подсказывайте те места, которые в наибольшей степени «режут и глаз и мозг!(с)?

В пункте «Распределители памяти» нет упоминания SLUB-аллокатора, который более широко распространён в современных дистрах, нежели SLAB.
Для той же Убунты:

$ cat /boot/config-3.0.0-12-generic |grep -e SLAB -e SLUB
CONFIG_SLUB_DEBUG=y
# CONFIG_SLAB is not set
CONFIG_SLUB=y
CONFIG_SLABINFO=y
# CONFIG_SLUB_DEBUG_ON is not set
# CONFIG_SLUB_STATS is not set

$ cat /boot/config-2.6.32-5-amd64 | grep -e SLAB -e SLUB
CONFIG_SLUB_DEBUG=y
# CONFIG_SLAB is not set
CONFIG_SLUB=y
CONFIG_SLABINFO=y
# CONFIG_SLUB_DEBUG_ON is not set
# CONFIG_SLUB_STATS is not set

Ну и где книга?

>> Слишком толсто, даже для ЛОРа.

Вам тоже понравилось? ;)

То есть, откровенно, признались, что троль?

И как к вам можно серьезно относится?

> Ну, попёрли комплексы неполноценности! И что??? Прям вот так сильно обидели по-жизни товарищи учёные??? Не допустили до кормушки-корыта???

бугага

это там-то кормушка?!

давай, подробно расскажи сколько получает «доктор наук, профессор», перед которым ты тут предлагаешь нам падать ниц, а мы все тут посмеемся

снаконец к самому цирюлику у меня единственная просьба: не надо позориться

ну почему ж «единственное»? есть ещё такое пожелание:

головной мозг у тебя есть?

отличай просьбы К человеку и ОТ человека

__________________________________________________________

в целом, мне не особо интересно с тобой препираться, потому что тебя успешно затроллить может и студент 2-го курса — особое удобство создает то, что ты легко воспринимаешь опечатку в твоей фамилии как личное оскорбление

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

Почитать можно: раз - http://lwn.net/Articles/229984/ два - http://kernel.org/doc/Documentation/vm/slub.txt

спасибо

давай, подробно расскажи сколько

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

в целом

А теперь, пожалуй, самое время: в игнор :(

Не знаю, обратил ли кто внимание:

#define KERN_EMERG "<0>" /* system is unusable */
#define KERN_ALERT "<1>" /* action must be taken immediately */
#define KERN_CRIT "<2>" /* critical conditions */
#define KERN_ERR "<3>" /* error conditions */
#define KERN_WARNING "<4>" /* warning conditions */
#define KERN_NOTICE "<5>" /* normal but significant condition */
#define KERN_INFO "<6>" /* informational */
#define KERN_DEBUG "<7>" /* debug-level messages */

Предшествующая константа не является отдельным параметром (не отделяется запятой), и (как видно из определений) представляет собой символьную строку определённого вида, которая конкатенируется с первым параметром (являющимся, в общем случае, форматной строкой). Если такая константа не записана, то устанавливается уровень вывода этого сообщения по умолчанию. Таким образом, следующие формы записи могут быть эквивалентны:

printk( KERN_WARNING, "string" );
printk( "<4>", "string" );
printk( "<4>string" );
printk( "string" );

Эти формы записи не эквивалентны. Сами же правильно пишете: «не отделяется запятой».

Эти формы записи не эквивалентны.

Естественно. Механически писал. Спасибо.

Да, дискуссия о деле перешла на личности, и дело ушло на задний план. Конечно, при «падении» модуля выдаётся не SEGFAULT & Co., а kernel oops.

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

Да, «упавший» в терминах user space, т.е. выполнивший недопустимую операцию.

он должен командой rmmod выгружаться.

Это теоретически или из опыта?

Вообще, когда пишешь user space программу или модуль ядра, оперируя указателями, операцией деления и прочими небезопасными конструкциями, оно у вас тоже, бывало, «падало»?

> Вообще, когда пишешь user space программу или модуль ядра, оперируя указателями, операцией деления и прочими небезопасными конструкциями, оно у вас тоже, бывало, «падало»?

Я не понял постановку вопроса: user space - это одно, оставим его в стороне, модуль - другое, конечно при отработке не раз и не два заваливается, да так, что система умирает мгновенно, временами и oops не успевает сформироваться (насколько помнится).

Афтар, а ты можешь выложить html-версию, не б-гмерзский pdf?

Книга вполне читабельна. Уже треть изучил и все работает.

Не без косяков конечно стилистический и других.

Например: printk( KERN_WARNING, «string» ); c ошибкой, запятая не нужна

Автор молодец.

Уже треть изучил и все работает.

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

Не без косяков конечно стилистический и других.

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

Например: printk( KERN_WARNING, «string» ); c ошибкой, запятая не нужна

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

А вот если ещё что при чтении бросится в глаза - сообщите, буду признателен.

>все драйвера видео X11 - они все в юзерспейс

man drm

man drm

1.

[olej@nvidia ~]$ man drm
Нет справочной страницы для drm
[olej@nvidia ~]$ uname -r
2.6.35.14-96.fc14.i686.PAE

2.

DRM(4)                  NetBSD Kernel Interfaces Manual                 DRM(4)
NAME
     drm -- Direct Rendering Manager (DRI kernel support)
Direct Rendering Manager
...

3. http://ru.wikipedia.org/wiki/Direct_Rendering_Infrastructure

Direct Rendering Infrastructure (DRI) — это интерфейс и реализация в виде свободного ПО, используемая в системе X Window System, позволяющая пользовательским приложениям безопасно получать доступ к видеоаппаратуре без необходимости использования X server (замедляющего этот процесс). Основное назначение DRI — обеспечение аппаратного ускорения Mesa, одной из реализаций OpenGL. Он также позволяет реализовать ускорение OpenGL на framebuffer console без запущеного X Server’а.

так БЕЗ X server? или ВМЕСТО X server?

... или просто чтобы языком ляпнуть? ;)

Если еще не заметили пример на стр.56 компилится если поменять местами

#include <linux/cdev.h>

#include "../dev.h"

Ядро 2.6.18-5.

А где можно взять уже готовые examples?

А где можно взять уже готовые examples?

Там же, ссылка в конце, названа «Архив примеров»:

http://rus-linux.net/MyLDP/BOOKS/Moduli-yadra-Linux/Kexamples.BOOK.tgz

Чем дальше влез, тем проблемнее компиляется - проблема в основном с путями к хедерам или их недекларированием.

В 'TOP'/dev/poll в исх. модуля половина типов неизвестна.

В каком ядре вы исходники проверяли? Повторюсь, у меня 2.6.18

В каком ядре вы исходники проверяли? Повторюсь, у меня 2.6.18

В разных ;)

Редко - в 2.6.18, основная часть в 2.6.32 - 35, что-то в 2.6.37

Чем дальше влез, тем проблемнее компиляется - проблема в основном с путями к хедерам или их недекларированием.

В 'TOP'/dev/poll в исх. модуля половина типов неизвестна.

О том, что так будет, я предупреждал в тексте: разработчики ядра с программерами не церемонятся ;) ... : «здесь вам не юзерспейс - это только для крутых пацанов!».

Но здесь уже, в обсуждениях, начали возражать и опротестовывать: «ах это не так, ах это не так...»

Ищите (я и текст писал с намерением не показать что и где написано, а как искать ... в этом смысле известная книга LDD3, которая основана на точных определениях хедеров - устаревает к моменту выхода очередного издания, и не компилируются их примеры вовсе). Очень много определений поменялось как раз начиная с 2.6.19 (всё, что касается обработчиков IRQ и др.), так что с 2.6.18 могут быть изрядные проблемы, связанные с восстановлением определений. Но всё можно найти.

Там же,

Текст, выложенный «там же» - будет (и уже) меняться, не значительно: с учётом присланных замечаний и указанных ошибок ... в том числе и вами на этом обсуждении.

Если кому интересно что и как и в каких пределах (относительно «меняться») - то подробности см. здесь: http://rus-linux.net/forum/viewtopic.php?f=3&t=1549

Теперь все понятно. Придется покопаться.

А как же пишут модули конторы для использования их на стороне? Например elcus имеет один исходник драйвера tmk1553b для всех 2.4.x и для всез 2.6.х. Неужто дефайнами разруливают...

А как же пишут модули конторы для использования их на стороне? Например elcus имеет один исходник драйвера tmk1553b для всех 2.4.x и для всез 2.6.х. Неужто дефайнами разруливают...

Драйвера NVIDIA (особенно если кто интересуется CUDA техникой программирования) приходится переустанавливать при малейшем обновлении номера сборки (даже не версии!) ядра... и будут они или не будут при этом собираться всегда вопрос загадочный.

Cisco Systems VPN Client - собирается только для одной единственной (и давней) версии ядра, для всех более новых - не собирается синтаксически, и народ бегает по интернету с самиздатовскими патчами и бубнами.

Дефайнами многие производители поддерживают некоторый (но ограниченный!) диапазон ядер, где оно собирается.

Не используйте экзотику, используйте типовые и зарекомендовавшие себя механизмы в своих модулях - ещё с большей вероятностью не будете нарываться на проблемы сборки.

А как же пишут модули конторы

А это проявляется ещё одно неотъемлемое достоинство моноядерной архитектуры ОС ;) ... о которых (достоинствах) тут уже один радетель заикался.

Ой, не трогайте Elcus пожалуйста.

Хоть посмотрите в их код для начала. Он один для WIN32 и Linux 2.4/2.6

Olej, спасибо за книгу.

Надеюсь, скоро можно будет приобрести бумажную версию

Надеюсь, скоро можно будет приобрести бумажную версию

1. это не от меня зависит, но обещают...

2. + вылизать ошибки, которые вылезают благодаря и таким обсуждениям.

dmi-a, а мы ведь ещё по QNX плотно контактировали? на qnx.org.ru ...

Книжку вот эту: http://www.books.ru/books/praktika-raboty-s-qnx-179608/ вместе издали ;)

> Ой, не трогайте Elcus пожалуйста.

Хоть посмотрите в их код для начала. Он один для WIN32 и Linux 2.4/2.6

Видел - приходилось копаться в них. Зато компилятся везде ))

Драйвера NVIDIA (особенно если кто интересуется CUDA техникой программирования) приходится переустанавливать при малейшем обновлении номера сборки (даже не версии!) ядра...

Есть такая проблема

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

а вот таких вопросов никогда не было. Есть на машине и 2.6.18 и 2.6.32 и вообще разные ядра собирал. Свежие версии драйвера nvidia всегда успешно компилятся, в том числе и на старых (для меня) ядрах

2. + вылизать ошибки, которые вылезают благодаря и таким обсуждениям.

Закинул в читалку, на досуге почитаю. Если что увижу - обязательно напишу.

dmi-a, а мы ведь ещё по QNX плотно контактировали? на qnx.org.ru ...

Да :)

Видел - приходилось копаться в них. Зато компилятся везде ))

Там всё сделано на define. Драйвер по сути очень простой, но реализован просто отвратительно. tmkwaitevents() блокируется на ядре и ждёт сигналов от ядра в основной тред. Благодаря этому, использовать его в многопточной программе немного затруднительно. Приходится изворачиваться. Это на 2.4 если что...

а вот таких вопросов никогда не было. Есть на машине и 2.6.18 и 2.6.32 и вообще разные ядра собирал. Свежие версии драйвера nvidia всегда успешно компилятся, в том числе и на старых (для меня) ядрах

Если вы этим много занимались, то, может сможете вот здесь что-то дополнить?:

http://rus-linux.net/forum/viewtopic.php?f=5&t=1530

- относительно NVIDIA+CUDA.

))) Да, летом было дело распараллелил cud'ой обработку изображений. Изучал все по howto с сайта nvidia. На 9800GT дало увеличение скорости в 10 раз. Понравилось. Правда глубоко не лез - копирование с хоста на девайс и обратно, запуск потоков, да код внутри девайса.

Проблем особо не было, драйвер встал без проблем (на 2.6.32), врядли что могу дополнить полезного

Правда, вспомнил, помудохолся с компиляцией. Линкование там странное какое-то - шаманил с перестановкой последовательности исходников при компиляции. И warning'и непонятные вылезали.

И не совсем понял, если написано 10 строк для cuda, то надо весь проект в nvcc компилить - вот где песня ;)

И не совсем понял, если написано 10 строк для cuda, то надо весь проект в nvcc компилить - вот где песня ;)

Там на одной из страниц обсуждения: http://rus-linux.net/forum/viewtopic.php?f=5&t=1530&start=10 - я уже прикреплял проект m.tgz, где часть CUDA кода компилируется (nvcc) из одного исходного файла, а остальные C/C++ - без nvcc (gcc) + раздельно компилированные части компонуются вместе... похоже, всё собирается.

Пытаетесь меня потролить? :-)

Потому, что я не поверю, что Вы не знаете про IPC, поскольку знаю, что Вы знакомы с QNX. Ну а то, что в режиме ядра коммуникация быстрее вроде как факт. Иначе, почему бы тогда всем осям не отойти от монолитной структуры и не стать, как QNX? Или QSSL удалось совершить технологический прорыв в этой области?

Ну а то, что в режиме ядра коммуникация быстрее вроде как факт.

Отнюдь не факт ;) - весь вопрос в том кто и с кем ... коммуникирует ;), сколько раз нужно переключать контекст (кольцо защиты, если x86). Посылайте сигнал (IPC?) из ядра (из модуля) процессу и, для сравнения, из процесса своему же потоку - и весь ваш «факт» рассыплется ;). Это простейший пример и так во всём: код в ядре ничуть не быстрее юзерспейс (с какой бы стати?) - разница только в переключениях контекста.

Иначе, почему бы тогда всем осям не отойти от монолитной структуры и не стать, как QNX? Или QSSL удалось совершить технологический прорыв в этой области?

Конечно удалось ;) ... только на том они и загнулись ;) ... и не QSSL, а Массачусетскому Технологическому, который передал для QSSL свои результаты многолетних исследований в этой технологии. И QSSL - удалось, а Таненбауму - не удалось, потому, что заигрался он ... но судят, к сожалению, о микроядерности по MINIX 3 - уродце в этом сесмействе ;)