Всем привет! Для того чтобы править миром не хватает малой части
Может кто на пальцах, схематично объяснить как устроены драйверы под юниксом?

Вот допустим у меня есть какой-нибудь ARM, на нем операционная система юникс. У ARM есть USB, и у меня есть Ethernet <-> USB типа LAN9730.

Что надо сделать чтобы можно было создать ТСР сокет который сможет подружиться с миром вокруг через этот езернет?
Я так понимаю что где-то в юниксе должен крутиться ТСР стэк и мне надо как-то умудриться входные данные с этого LAN подать в него, а выходные в LAN. А также настроить этот LAN на работу.

Или допустим я хочу пошевелить ногами или послать данные через UART. Как это делается? Не обращаться же напрямую в регистры проца из юникса, да это и не возможно как я понимаю.

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

Заранее спасибо!

http://dchekmarev.ru/blog/article/1252939707

что-то я не настолько просветлен... можно чуть более подробно?

какое это имеет отношение к драйверам unix-систем?

Касательно драйверов могу посоветовать почитать книгу "Linux device drivers".

В целом бестолковая книга.
Более практичная - "Essential Linux Device Drivers"

Но даже в ней нет упоминания RNDIS который нужен для USB-Ethernet адаптеров

Так что правы те у кого такие вопросы вызывают приступы немотивированного сарказма.

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

По сути вопроса. Очевидно что за 1 тему на форуме невозможно научиться писать драйвера, а главное что сейчас это и не требуется. Ближайшей моей задачей является понимание их работы, понимание того как идут данные.

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

Вопрос же не в конкретном переходнике USB-Ethernet. В это же USB может быть воткнут GPS приемник или еще что-то. А на юниксе сверху может стоять андроид с его классами работы с GPS или чем-то еще. И мне хочется понять как так делают что все срастается... Ведь не могли же люди писавшие яву машину предусмотреть все варианты устройств подключаемых к портам и так далее, а тем не менее оно все как-то работает...

Так что если можно без немотивированного сарказма, максимально упрощенно как все работает?


А правильно я понимаю что если RNDIS поддержан в операционке (говорим про юникс), то достаточно сделать USB устройство с правильным протоколом, и данные с него пойдут в ТСР? То есть USB-WiFi может работать по тому же принципу, и в целом может быть даже какой то USB-RS485, на котором так же можно будет поднять ТСР сеть?

Слишком общие вопросы задаете, сложно отвечать
Попробуем конкретизировать:
1. может все-таки не unix, а linux?
2. у вас уже имется какое-то устройство (или отладочная плата) на ARM9 с установленным linux или вы пока просто фантазируете на тему?
3. сразу стремитесь познать драйвера, а есть ли опыт разработки по linux? простой опыт работы с linux?
4. наверняка у вас есть конкретная аппаратно/программная задача, может обрисуете?



Боюсь, что на пальцах вам здесь не расскажут.

По встраиваемому линуксу можно почитать например здесь или здесь.
По драйверам здесь.

1 - да наверное. Я их путаю, наверное линукс
2 - скорее фантазирую, вероятнее всего будет что-то типа odroid-u3
3 - Работа на настольных компутерах, очень базовое представление. И я даже не столько стремлюсь познать драйвер. Я прекрасно знаю как пошевелить ножками ARM вообще и в целом, то есть как работает проц, периферия, но я хочу понять принципы работы с железом из линукса, именно с начинкой проца.
4 - Та задача которая есть это скорее самообразование, хочется продвинутся в вопросах "взрослых-распространенных-пользовательских" операционок под железо. Хочу попробовать подтянуть железо под андроид, который в базе ядро юникса-линукса не знаю кого там...



Жаль. Мне надо в общих чертах чтобы хотя бы понимать какие вопросы надо задавать. За ссылочки спасибо, поизучаю.

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

Я же говорю внятной документации на реализацию RNDIS в линуксе нет. Там все архаично и безсистемно.

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

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

Т.е. написав драйвер для UART-а вы все равно мало что будете понимать в драйверах для Ethernet-а.
Потому что это не драйверы, а целые стековые архитектуры с совершенно неповторимыми API между слоями стеков.

Посмотрите еще:
Написание драйвера для LCD дисплея под embedded linux
Разработка драйвера ведомого SPI устройства для embedded Linux

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


Да я читаю, скорее всего это как раз то что мне нужно, правда думал что объемчик будет поменьше


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





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

если совсем на пальцах, то USB kernel API с одной стороны и NETLINK kernel API с другой.
а как вы этот драйвер писать будете - зависит от возможностей, заложенных непосредственно в чип, алгоритм строится под конкретную железку.
т.е. без детальной документации на него не обойтись. И, если в документации на чип алгоритм не описан, - то ещё плюс немного смекалки и фантазии.

понятно дело что как работает железка - это известно. А сам драйвер - это фактически процесс который крутиться и пихает данные при помощи этих API? А как получать запросы от ТСР стэека которые надо в USB передать? Обработка колбэков или можно как-то событие зарегистрировать или как это в линуксе называется? А ведь еще надо как то сказать что Сокету что они именно через ваш драйвер наружу должны стучаться, то есть как-то сделать этот EthX через который полезут данные...

Я так понимаю RNDIS примерно этим и занимается?

я к сожалению не знаю что за RNDIS - это по моему что-то виндовое.

да, через NETLINK можно EthX зарегистрировать.

http://free-electrons.com/doc/training/lin...rnel-slides.pdf

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

спасибо за ссылочку

Бардак там полный.
Например плата BeagleBone очень хорошо работает с сетью через USB, но для этого использует не RNDIS, а некий пакет драйверов Windows Driver Package - Linux Developer Community Net
Но подите найтиде исходники этих драйверов.

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

И как вы думаете продвинуться в изучении этих технологий?
Все что остается в открытом линуксе это играться с UART-ми, I2C, SPI и прочей мелочью.

И что делать? Брать готовые сборки от производителя плат?
Я чет думал что по уму надо было бы сделать свои драйверы под нужные задачи. Но как понимаю это неподъемная задача в разумные сроки.

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

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

Или это все к тому что надо вместо линукса ставить другие оси для процов и не придумывать?

расскажите это интелу.

PCIe сетёвка х540
даташит: http://www.intel.com/content/dam/www/publi...0-datasheet.pdf
там алгоритм работы расписан весь.
и драйвер в mainline - ixgbe_x540.c
и где там что закрыто/засекречено?

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

а закрытую часть то откуда брать? На просторах интернета? А они кривыми не бывают? А если кривые то не переделать?

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

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

Полная картина тут заключается в том, что, в подавляющем большинстве, некие похожие драйверы имеются где-либо на просторах сети, и имеют примерно единообразное форматирование кода и принцип комментирования. В результате, найдя пару-тройку исходников "вроде как около по теме", и посидев с ними часов так 48...96, вполне можно родить свой драйвер, выполняющий нужные по ТЗ функции (конечно, время может и сильно увеличиться от объема реальных работ).

И забудьте о "стандартизации" в линуксе. Стандартизация - это путь к неадекватному пожиранию ресурса и к лишним, никому не нужным, кроме "стандартизаторов" расходам. К притмеру, именно поэтому Windows XP до сих пор живее всех живых, несмотря на то, что труп уже, а windows-8/9/10/e.t.c. удел поставщиков новых систем, где выбора нет, и зомбированных микрософтом пользователей. Линукс тем и хорош, что необходимый минимум функциональности делается достаточно просто и относительно быстро - главное, потратить несколько ночей на то, чтобы вникнуть, что там в ядре к чему. Дальше все вопросы сами отпадут.

И начинать надо не с NDIS/USB, а с чего попроще - с дрыганья ногой (ну или считывания какого нибудь регистра) через I2C например. Ну а там, потом, чем дальше в лес, тем толще партизаны...

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

UPD:
Ну, и, это... Если Вы дока в написании драйверов под windows - то забудьте, все, что знаете... Никаких IRP там нет, и ничего похожего тоже... Есть просто вызов функций, прямой. И Вы можете вызвать любую функцию ядра линукса, или другого драйвера, от которого зависите. То есть, все просто, понятно и прозрачно - все ядро - это, как бы, единая программа, внутри которой можно вызвать любую функцию (экспортированную, естественно) любого модуля. То есть вся организация всех очередей запросов - чисто на Вашей совести.

ага спасибо, вот читаю, вникаю. Ближе к делу появятся, наверное, конкретные вопросы, пока читаем доки

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

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

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

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

Заголовочные файлы, естественно, все есть, include/linux/...... в ядре, но для сборки дров они и отдельно существуют.

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

то есть добавление драйвера - это всегда модификация ядра? Интересно, то есть к готовому ядру ничего добавить нельзя, надо его пересобирать?

Интересно как работает NDK для андроида, которая позволяет дописывать низкоуровневые части работы с железом проца и вроде не ломает ядро, может там правда уже в ядре ответная часть прописана как то....

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

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

UPD:

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

у меня 2 варианта
либо через usb в ethernet, и надежда на то что в ядре уже есть драйвер аля RNDIS, и все произойдет само собой
либо что немного более правильно через SPI, I2S и так далее, но к ним точно драйверов не будет. И особенно доступа из андроида, и тут надо будет написать драйвер, и причем не трогая ядра, а то поговаривают в гугл маркет пускать перестанут...

Но в познавательных целях хочется все варианты и чуть ли не RNDIS повторить...

В проекте http://virt2real.ru/ используется ethernet через USB. Исходники ядра доступны. Можете посмотреть, как там сделано.

спасибо

Через I2C можно тоже работать из юзер моды. Через SPI, вроде, тоже. I2S (не ошиблись??) это уже прерогатива аудио-подсистемы.
Написать драйвер SPI или I2C-устройства - это элементарщина (см. для примера драйвера в input разных клавиатурных микрух.) Но, повторюсь, через эти интерфейсы можно работать и из юзер-моды через драйвера SPI или I2C мастеров.

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

то есть получается что все уже написано до нас, бери и работай? А где место подвигу?

Вот когда после загрузки вашего драйвера в систему что-то пойдёт не так - вот тогда и будет место подвигу.
А оно обязательно будет!

В общем, да, для решения простых задач через USB, I2C и SPI все сделано до нас. Бери и пользуйся сразу из юзер спейса. С I2S - вот там место подвигу вполне найдется

PS
И еще место подвигу будет, когда оно с пол-оборота не заработает, или kernel panic получится где-то вдалеке от драйвера... Я вот доходил до патченья глюков в недрах инициализации клоков, резетов и доменов питания одного процессора... Который вылез с совсем неожиданной стороны, после написания, кажется, драйвера видеозахвата, работающего через видеопорт... ну вот как-то так... Типа дернул за веревочку, а взорвалось в соседней области

понятно, спасибо на добром слове

Я, имея солидный опыт в электронике и программировании микропроцессоров, "лез" на уровень драйверов Линукса несколько лет. Не скажу, что все время этим занимался, но изучал в свободное время. Там надо понимать что такое ядро. Уметь его компилировать, знать как его конфигурировать. Знать как устроена структура исходников ядра. Где расположены файлы платы и мого многое другое, что явно не относится к написанию драйвера. Если на пальцах, то ответ получится точный, но бессмысленный.
Драйвер в Линух (Юних) это код, который бежит в пространстве ядра и имеет интерфейс доступа файла. Написав соответствующим образом функции read/write, вы, читая этот файл или записывая в него будете обмениваться данными с вашим устройством.

Вот эти книжки (их можно скачать из сети) помогут вам разобраться в дополнительных знаниях вокруг драйверов Линукса.
http://www.amazon.ca/Embedded-Linux-Primer...d/dp/0131679848
http://www.kroah.com/lkn/

А на этом сайте можно найти много интересной информации.
http://free-electrons.com/



Уточнение. В Линукс системе как правило уже есть драйвры SPI и I2C, которыми можно воспользоваться без написания специального драйвера, но также можно и написать драйвер для доступа к определенному устройству на указанных шинах. В документации ядра есть пример доступа к таким устройствам без написания драйвера:
https://www.kernel.org/doc/Documentation/i2c/dev-interface

Документация на I2C
https://www.kernel.org/doc/Documentation/i2c/
Документация на SPI
https://www.kernel.org/doc/Documentation/spi/

Документация на все ядро
https://www.kernel.org/doc/Documentation


100%