изначально да виндовое, но есть мнение что некоторые линуксы-юниксы его имеют в комплекте, потому что он через 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 года подобной работы, успешно решал поставленные задачи, не сталкиваясь или обходя закрытые места.

Сообщение отредактировал samike - Oct 16 2014, 11:03

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

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

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

Полная картина тут заключается в том, что, в подавляющем большинстве, некие похожие драйверы имеются где-либо на просторах сети, и имеют примерно единообразное форматирование кода и принцип комментирования. В результате, найдя пару-тройку исходников "вроде как около по теме", и посидев с ними часов так 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-устройств.