[Lagman 1]

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

Без root-прав - сиди в пользовательской песочнице.

А если у файла установлен атрибут setuid?

[Olej 0]

А если у файла установлен атрибут setuid?

А если у файла установлен атрибут setuid, то установлен он не от Духа Святого :laughing: , а вы его сами установили, и, хотелось бы думать, что зная зачем это делаете.

Ну и т.д. ... про setuid в этом качестве множество написано, и про нежелательность его использования вообще ... и все дальнейшие обсуждения в этом направлении будут уже просто бла-бла-бла...

 

 

Чтоб ... не растекаться умом по древу, не разводить словопрения - подведём как итог: то, что ТС-ра интересует и что он спрашивает, сводится к следующему:

- как можно читать/писать в Linux по портам и наблюдать обменные операции?

- обязательно ли для этого писать модуль ядра Linux, чтобы доступ к портам осуществлять в супервизорном режиме процессора (кольцо защиты 0)?

 

Ответы можно сгрупировать так:

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

- операциями типа inb(), outb() ...

- и это именно не машинные привилегированные команды, как в ядре, а системные вызовы Linux...

- в чём можно убедиться (обращаем внимание на 2):

$ man 2 inb

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

- кроме того, специально предоставляется ещё и специальное символьное устройство /dev/port для доступа к портам.

 

А итог:

- во многих (достаточно многих) случаях, когда нужно обслуживание внешнего устройства (ввод-вывод)...

- если есть возможность это написать без написания модулей ядра, в пространстве пользователя - то именно это и есть предпочтительное решение

- и многие крупные девелоперские проекты Linux последнего времени были направлены именно на создание и предоставление таких инструментариев: libusb, файловая система FUSE ... да и udev, netlink и sysfs.

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

 

P.S. Если кто интересовался архитектурой микроядерных ОС, то он вспомнит, что в них обеспечивается устойчивость и жизнеспособность на порядки выше, чем во всех Linux и Windows вместе взятые :rolleyes:, именно за счёт того, что драйверы там вынесены из супервизорного режима (ядра), выполняются либо в пользовательском пространстве, либо в промежуточных кольцах защиты (1 или 2) процессора.

[Tarbal 4]

P.S. Если кто интересовался архитектурой микроядерных ОС, то он вспомнит, что в них обеспечивается устойчивость и жизнеспособность на порядки выше, чем во всех Linux и Windows вместе взятые :rolleyes:, именно за счёт того, что драйверы там вынесены из супервизорного режима (ядра), выполняются либо в пользовательском пространстве, либо в промежуточных кольцах защиты (1 или 2) процессора.

 

Именно: segmentation fault в пространстве пользователя приведет к краху апликации, а в ядре к краху системы. Однако я хотел бы указать на реальную опасность бездумного использования доступа ко внутренней памяти устройств. В embedded устройстве, записав неправильное значение в регистры PMIC (Power Management Integrated circuit), можно сжечь ваше устройство. Иногда даже чтение может привести к тяжелым сбоям. Некоторые устройства сбрасывают флаги событий автоматически при чтении статуса. Какие-то события не дойдут до назначения. Мой совет если надо писать в регистры -- семь раз подумай. Наличие простого способа доступа к памяти (устройствам) позволяет тем, кто не осилит написать и установить драйвер убить систему.

[Tarbal 4]

Неправилно сказали :smile3009:

Программный код пользовательского режима вполне может (с существенными ограничениями) обращаться к регистрам внешних устройств. См. прямо в системе man по:

ioperm(2), iopl(2), inb(2), outb(2), capabilities(7) и т.д. (процессор i386 только).

Кроме того, Linux предоставляет даже специальное символьное устройство /dev/port для прямых чтения и записи в порты внешних устройств (с правами root, естественно).

 

Более того, во многих случаях в Linux всячески поощряется организация ввода/вывода именно из пространства пользователя, без написания модулей ядра (драйверов). Для того делаются специальные и достаточно сложные инструменты промежуточного слоя. Самые известные тому примеры: проект libusb и файловая система FUSE, на которых в последние годы реализуется стандартная поддержка тысяч разнообразных устройств от их производителей.

 

P.S. Детали и примеры использования всего этого хозяйства можете посмотреть здесь: Практикум по Linux Kernel.

 

ТС навряд ли использует i386. Скорее всего ARM. В обычном Линуксе для доступа к регистрам я делаю следующим образом. Сначала смотрю по каким адресам зарегистрированы регистры в псевдо файле: /proc/iomem.

Все последуящие операции производятся пользователем root.

Потом, используя map для устройства /dev/mem, получаю доступ к области памяти. Насколько я понимаю вопрос: Если область памяти не зарегистрирована в ядре (что мы и видим в /proc/iomem), то до памяти не достучишься. Как обстоит дело с вашей системой я не знаю. Дело в том, что операция map производится для того, чтобы получить виртуальный адрес, соответствующий искомому физическому. ucLinux не нуждается в такой операции ибо у него нет виртуальной памяти.

Попробуйте напрямую писать и читать в область памяти из /proc/iomem, соответствующую вашему устройству.

Я сейчас пишу в свободное время утилитку для подобного доступа к регистрам. Будет готова -- дам ссылку.

[Olej 0]

Я сейчас пишу в свободное время утилитку для подобного доступа к регистрам. Будет готова -- дам ссылку.

Интересно бы

[Tarbal 4]

Интересно бы

 

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

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

Ведь от нее есть и польза если не злоупотреблять.

Например надо подобрать значения регистров в таймере, чтобы настроить PWM -- из апликации попробовал и сразу увидел результат.

 

 

[Tarbal 4]

Выложил:

https://github.com/stepanovr/linuxreg

 

Поскольку делал для Raspberry PI, то на 32 бита получилось. 64 бита криво выглядят -- надо будет найти время.

Вам, olej, она навряд ли подойдет. Ведь вы в основном на 386 архитектуре, а она сегодня 64 бита.

 

Знаю, что много криво сделано, но это мой первый опыт на ncurses. Тем более я больше драйверами и реалтаймом занимаюсь, а здесь понадобился интерфейс пользователя какой-никакой.

 

Посмотреть все детали доступа к регистрам можно в фаиле app/rdmem.c

 

[andrew_b 15]

Есть программка devregs: https://community.nxp.com/docs/DOC-97543

https://github.com/boundarydevices/imx-util...ter/devregs.cpp

 

[ltDrakon 0]

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

 

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

[Tarbal 4]

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

 

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

 

Как раз для малинки и делал :) В документе даны неверные адреса GPIO. Потерял время на бодание. Моя апликация находит правильные адреса и показывает их.

Попробуйте на малнке.

Да и не всегда есть время писать.

 

Есть программка devregs: https://community.nxp.com/docs/DOC-97543

https://github.com/boundarydevices/imx-util...ter/devregs.cpp

 

Ну да. Совершенно аналогично. Как я ранее и описал метод доступа. Правда ограничено для использования только на Frescale imx6X и imx53. И наверное только какой-то специальный Линукс. Я не очень внимателен, но не встречал такого файла (псевдо файла) /etc/devregs.dat. Думаю, что это какой-то специальный случай.

 

Интересно бы

 

Пользуясь случаем хочу выразить вам благодарность от читателя. Во многих документах по open source описание понятно только тем кто "посвящен". Вот например библия по драйверам Линукс. Три автора Corbet, Rubini и Kroah-Hartman.

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

Ваши книги понятны и новичкам. При том что все понятно изложен материал о совсем непростых вещах.

 

Правда неплохо детали установки, компиляции и разных свойств ядра описаны в Linux Kernel in a Nutshell автор (тот же из драйверов) Greg Kroah-Hartman. Но она не о драйверах и модулях. Но это скорее исключение.

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

 

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

 

Я предлагаю администрации форума (модератору) сделать прикрепленную тему, где olej выложит ссылки на свежие версии своих книг. Если он конечно не против.

[andrew_b 15]

Ну да. Совершенно аналогично. Как я ранее и описал метод доступа. Правда ограничено для использования только на Frescale imx6X и imx53.

Легко портируется на другой ARM. Например, мы её используем и для ls1020.

И наверное только какой-то специальный Линукс.

Линукс обычный.

Я не очень внимателен, но не встречал такого файла (псевдо файла) /etc/devregs.dat. Думаю, что это какой-то специальный случай.

У многих программ есть конфигурационные файлы. /etc/devregs.dat -- это конфигурационный файл программы devregs. Но она может работать и без него. Просто devregs.dat удобен для описания регистров, чтобы можно было использовать не "голые" адреса, а символические имена, и даже отдельные поля.

[Tarbal 4]

Легко портируется на другой ARM. Например, мы её используем и для ls1020.

Линукс обычный.

У многих программ есть конфигурационные файлы. /etc/devregs.dat -- это конфигурационный файл программы devregs. Но она может работать и без него. Просто devregs.dat удобен для описания регистров, чтобы можно было использовать не "голые" адреса, а символические имена, и даже отдельные поля.

 

Я подумал, что /etc/devregs.dat это псевдо файл, хотя мог бы и сообразить по месту положения, что конфигурационный. Торможу. Псевдо файлы в /proc и /sys.

А кто заполняет или откуда брать такой конфигурационный файл для, скажем, Sitara процессора?

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

За критические отзывы буду признателен.

Там еще не отлажен механизм восстановления после изменения размера окна терминала в процессе работы. Плюс к другим недостаткам.

[Olej 0]

сделать прикрепленную тему, где olej выложит ссылки на свежие версии своих книг. Если он конечно не против.

Не знаю, нужно ли отдельную тему, а всё, что меня интересовало в последние 2-3 года (или больше) описано и свободно доступно здесь: Linux для программиста.

Пользуйтесь на здоровье. :rolleyes:

[Tarbal 4]

Не знаю, нужно ли отдельную тему, а всё, что меня интересовало в последние 2-3 года (или больше) описано и свободно доступно здесь: Linux для программиста.

Пользуйтесь на здоровье. :rolleyes:

 

Спасибо. Запишу ссылку. Сейчас собираю литературу по сетевым драйверам. Лучшее что нашел документ Linux Kernel Networking by Rami Rosen. Посмотрю если у вас есть что-нибудь по сетевым драйверам.

[ltDrakon 0]

Как раз для малинки и делал :) В документе даны неверные адреса GPIO. Потерял время на бодание. Моя апликация находит правильные адреса и показывает их.

...

 

тама смещенные адреса - тоже пободался чутка, было дело ..

 

факт лишь тот - что прямой доступ только по руту или драйвер ...

 

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