Xenomai + LinuxCNC, EVL + LinuxCNC из исходников

Olej · Сообщение **Olej** » 09 июл 2018, 19:30

Maxekb77 писал(а):А можно для простых смертных, наФига оно надо ?

Можно.
Для того, чтобы получить hard realtime систему (RTDM) и приложения (Xenomai API).
Что означает а). реакцию на любое аппаратное прерывание, событие гарантировано в интервале, скажем 1 ms, б). то что любой (ну, почти любой ... основные) системный вызов (man -s2 ...) от realtime задачи не может быть прерван любой другой Linux задачей.
Т.е. это нужно ("нафига") для управления критической аппаратурой, которой недопустимо пропустить крайнее время реакции (deadlock) на событие.
Картинки, графики временных задержек (от события на контакте GPIO до реакции на другом контакте GPIO) посмотрите: How fast is fast enough? Choosing between Xenomai and Linux for real-time applications. Там очень хорошо видно, что в стандартном Linux задержка при типовом значении 20мкс. (изредка, иногда) может составить и 350 и 500 мкс. А в любых Windows клонах это могут быть и большие единицы мс.

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

Из всех реализационных решений (исключая всякие эксперименты) Xenomai на сегодня, пожалуй, единственное приемлемое решение.
Альтернативой может быть (и 20-30 лет было) использование дорогих проприетарных операционных систем: QNX, pSOS, VxWorks, ...

Maxekb77 · Сообщение **Maxekb77** » 09 июл 2018, 19:44

Figure 5: cross-configuration periodic experiments: maximum and 95% envelope jitter magnitudes plotted
on a log scale. Transmission time for 12 serial bytes at 115200bps ( 87µseach) is plotted for comparison.
Config Experiment # samples Median 95% 100%
stock linux-chrt-user 1018391 -2µs 69µs 1205µs
rt linux-chrt-user 1018387 -1µs 47µs 158µs
xeno xeno-user 1018318 -1µs 34µs 57µs
stock linux-kernel 1018255 0µs 17µs 504µs
rt linux-kernel 1018249 0µs 24µs 98µs
xeno xeno-kernel 1018449 -1µs 23µs 41µs
--------

Olej писал(а):Из всех реализационных решений (исключая всякие эксперименты) Xenomai на сегодня, пожалуй, единственное приемлемое решение.
Альтернативой может быть (и 20-30 лет было) использование дорогих проприетарных операционных систем: QNX, pSOS, VxWorks, ...

----
Спасибо , понятно "попытка достичь скорострельности дос под линуксом"

Olej · Сообщение **Olej** » 09 июл 2018, 19:46

going писал(а): Ресурсы:
https://xenomai.org/
http://xenomai.org/installing-xenomai-3-x/
http://xenomai.org/building-application ... nomai-3-x/
http://xenomai.org/running-applications ... nomai-3-x/
http://xenomai.org/migrating-from-xenomai-2-x-to-3-x/
http://xenomai.org/documentation/xenoma ... index.html
http://xenomai.org/troubleshooting-a-du ... iguration/
http://xenomai.org/troubleshooting-a-si ... iguration/

Вот чуть ли не самый важный, по использованию, ресурс: POSIX interface. POSIX интерфейс (в Xenomai такие интерфейсы они называют ещё skin, скины) появился достаточно поздно, недавно ... в 2.6.Х его не было (или был в самых последних).
Там же (по ссылке) рядом - скины: VxWorks® , pSOS® , Alchemy API (это нативный скин Xenomai)...

Вообще, там вы найдёте подробную документацию по использованию Xenomai 3.0.6.

Olej · Сообщение **Olej** » 09 июл 2018, 19:53

Maxekb77 писал(а): Спасибо , понятно "попытка достичь скорострельности дос под линуксом"

Почти так

... потому как в DOS крутится одна-единая ваша задача, и она детерминирована... или всё то же самое в ... микроконтроллерных аппаратных перделках, всех этих: PIC, AVR ... Arduino...
А в современных операционных системах, нужно оно вам или нет, крутится 50-100-200 конкурирующих процессов-потоков, дерущихся за процессоры и за время.

Только не совсем "скорострельности". Потому что скорость можно менять взяв процессор в 100 раз быстрее... или в 20 ядер. Но детерминированность реакции, гарантированность времени этим не возрастёт ... как тормозил Windows на 1мс. "временами", так и будет тормозить на те же 1мс.

going · Сообщение **going** » 09 июл 2018, 19:59

Olej писал(а):Про ARM - не верю.
ARM можно собрать только под конкретный SoC, а не "ARM-вообще".
Откуда брали .dts, DeviceTree ... а ещё хуже - оверлеи DeviceTree, как для Rapsbery Pi.

Мне что книгу написать про то, что и как я делал? У меня времени на это нет.

А если серьезно, то давай договоримся так:
Для ARM я собирал только для Allwiner чипов: A83T, H5, A64
Использую системы сборки:
а) оригинальные от производителя платы (только uboot, dtb, kernel устаревшие)
б) Armbian build (ubuntu)
в) своя собственная, которая собирает OpenSUSE

для x86, x86_64 только rpmbuild на хосте с OpenSUSE. Этого достаточно.

В этом спектре я готов обсуждать. Если у Вас на каком то этапе ошибка, я могу посмотреть у себя, как этот этап реализован.

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

Задавайте по одному узкому конкретному вопросу.

Olej · Сообщение **Olej** » 09 июл 2018, 21:42

going писал(а): Для ARM я собирал только для Allwiner чипов: A83T, H5, A64
Использую системы сборки:
а) оригинальные от производителя платы (только uboot, dtb, kernel устаревшие)
б) Armbian build (ubuntu)
в) своя собственная, которая собирает OpenSUSE

Какое ядро, цифра?
Если kernel устаревшие, то откуда брался патч ipipe?
Armbian build (ubuntu) на сегодня, позволяет сборку только для ограниченного набора mainline kernel, собственно, одно ядро из числа последних, выбранных как mainline ... по состоянию на 08.06.2018 это была сборка что-то типа linux-image-next-sunxi_5.46_armhf.deb:

Код: Выделить всё

olej@orangepione:~$ uname -a
Linux orangepione 4.14.14-sunxi #1 SMP Thu Jan 25 12:20:57 CET 2018 armv7l GNU/Linux

olej@orangepione:~$ lsb_release -a
No LSB modules are available.
Distributor ID:   Debian
Description:   Debian GNU/Linux 9.4 (stretch)
Release:   9.4
Codename:   stretch

Но это 4.14.14 - это не 4.14.36, единственное для которого есть патч ipipe.
Если собирать Xenomai Mercury (без патча ipipe) - то всё собирается... но это абсолютно неинтересно.
А как вы патчите ядро 4.14.36 патчами для 4.14.14 - это уже вопрос? Это может проконать ... но случайно, "на грани фола".
Но самый главный вопрос: какой командой-утилитой вы накладывали ipipe патч на ядро?
Ну и следующий вопрос: какую версию Xenomai вы установили в созданной системе?
Так будет достаточно конкретно?

going писал(а): для x86, x86_64 только rpmbuild на хосте с OpenSUSE. Этого достаточно.

Для x86 не интересно - там всё собирается.
По крайней мере, если тупо повторять шаги инструкции Xenomai.
Но там нет RTDM множества драйверов и, скорее всего, уже никогда не будет никогда.
P.S. Хотя ... будет интересно, но если не тупо повторять инструкции от Xenomai в десктопном дистрибутиве, а если это удасться собрать в специализированной системе сборки BuildRoot для минимальной embedded системы ... без графики, без всяких мультимедийных свистелок и перделок, без 2-х десятков бэкэндных сервисов-демонов, без пакетной системы ... с BusyBox вместо bash и 50-ти отдельных программ-утилит GNU и т.д. Т.е. если вместо 1.5-2Gb системы собирать образ ... на 50Mb.

Olej · Сообщение **Olej** » 09 июл 2018, 22:07

going писал(а):
Olej писал(а):например, RT-драйверы GPIO доступны только для нескольких образцов под ARM,
В документации изложено, как написать дополнительный код для нового Soc.

Там написана херня - к этому при обоюдном согласии мы пришли в неоднократном обсуждении непосредственно с Philippe Gerum <rpm@xenomai.org>, последним активным, собственно, автором кода Xenomai, который работает над кодом исключительно под ARM. И метода эта вся описанная годится только под ARM, потому как заточена исключительно под описания DeviceTree, а не PCI API. А под x86 DeviceTree не используется, и вся эхта методика не годится.
Поэтому за годы проекта Xenomai у них так и нет работоспособного RTDM драйвера такого элементарного драйвера, как Realtec 8169 ... и его пишут во что горазд сторонние разработчики, где кой-чего работает, а кой-чего нифига

И если написать RTDM-драйвер для Realtec ещё кое-как возможно (многие уже лет 5 пытаются

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

Olej · Сообщение **Olej** » 10 июл 2018, 01:02

going писал(а): А если серьезно, то давай договоримся так:
Для ARM я собирал только для Allwiner чипов: A83T, H5, A64
Использую системы сборки:
а) оригинальные от производителя платы (только uboot, dtb, kernel устаревшие)
б) Armbian build (ubuntu)
в) своя собственная, которая собирает OpenSUSE

Я начинаю догадываться в чём у нас разные взгляды на одни и те же вещи - могу предположить:
- вы пропатчили ядро ipipe ...
- и собрали ядро, образ системы...
- даже, возможно, накатали образ системы на SD-карточку
- и даже загрузили эту систему.
Но, как я предполагаю, вы:
- не собирали userspace дистрибутива Xenomai (3.05, 3.06, или 3.07)
- не инсталлировали собранное в патченой системе
- и не проверяли хактеристики (успешность) собранного ... хотя бы, для простоты и скорости, только встроенными инструментами Xenomai.
Если так, то именно на сборке userspace дистрибутива Xenomai и вылазят ошибки сборки.

going · Сообщение **going** » 10 июл 2018, 17:54

Olej писал(а):Armbian build (ubuntu) на сегодня, позволяет сборку только для ограниченного набора mainline kernel

Armbian build, на ветке master, на текущий момент собирает ядро v4.14.54
это последний тег v4.14.y - поведение по умолчанию, но тег ядра можно задать какой хочешь.
Из последнего собранного "linux-sunxi64-next_4.14.19_5.51_config"
Как видите патч ipipe-arm64-v4.14.4.patch я применил к ядру v4.14.19 без переделки.
Далее вверх идут серьёзные изменения в коде ядра в 3 файлах.

Olej писал(а):Но самый главный вопрос: какой командой-утилитой вы накладывали ipipe патч на ядро?

patch

Olej писал(а):Ну и следующий вопрос: какую версию Xenomai вы установили в созданной системе?

Текущая на сегодня на ветке next (xenomai.git) 3.0.9

Olej писал(а):это не 4.14.36, единственное для которого есть патч ipipe.

Да патч для 4.14.36. Варианты: 1) установить тег v4.14.36 2) Попробоват применить к более старшей версии и если применяется без ошибок то выбрать её

Olej писал(а):Т.е. если вместо 1.5-2Gb системы собирать образ ... на 50Mb.

Я не вижу проблемы. Система сборки, что Armbian, что BuildRoot -это набор скриптов переопределить их поведение довольно просто.
Задайте свой набор пакетов (библиотек) для установки и получите требуемое.

Olej писал(а):Там написана херня

Olej писал(а):метода эта вся описанная годится только под ARM

А собственно самый наиглавнейший вопрос: Что требуется? Вроде бы

Olej писал(а):Для x86 не интересно - там всё собирается.

Olej писал(а):Я начинаю догадываться в чём у нас разные взгляды на одни и те же вещи

В формулировках дело:

Olej писал(а):именно на сборке userspace дистрибутива Xenomai и вылазят ошибки сборки.

Ошибки которые вылазят во время процесса сборки, или ошибки, которые вылазят во время работы не корректно собраной системы или ядра???

Olej писал(а):и не проверяли хактеристики (успешность) собранного

Да. В этом загвоздка. Образ с ядром 4.17 вывалил кучу ошибок (Что то не корректно я сделал). Их надо исправлять и перепроверять.
Для этого образ (пакет для установки) должен собираться автоматом, а не в полуручном режиме.
В данную минуту работа в процессе.
Пока откатился на v4.14.19 и отлаживаю систему сборки.

going · Сообщение **going** » 10 июл 2018, 18:15

Olej писал(а):Но, как я предполагаю, вы:
- не собирали userspace дистрибутива Xenomai (3.05, 3.06, или 3.07)
- не инсталлировали собранное в патченой системе
- и не проверяли хактеристики (успешность) собранного ... хотя бы, для простоты и скорости, только встроенными инструментами Xenomai.
Если так, то именно на сборке userspace дистрибутива Xenomai и вылазят ошибки сборки.

Теперь моя очередь догадываться.
Вы собираите в BuildRoot. ( там uglibs? )
На этой ситеме сборки основаны все оригинальные BSP производителей плат с устаревшими ядрами.
Ошибок там море. И недоделок то же. По крайней мере 2 года назад так было. Я от неё отказался и написал свою.
Вы собрали ядро ipipe и библиотеки Xenomai, а добавившийся функционал в дереве объектов не прописали или прописали не корректно?

Давайте вместе разбираться.

Olej · Сообщение **Olej** » 11 июл 2018, 10:53

going писал(а):
Olej писал(а):Но, как я предполагаю, вы:
- не собирали userspace дистрибутива Xenomai (3.05, 3.06, или 3.07)
- не инсталлировали собранное в патченой системе
- и не проверяли хактеристики (успешность) собранного ... хотя бы, для простоты и скорости, только встроенными инструментами Xenomai.
Если так, то именно на сборке userspace дистрибутива Xenomai и вылазят ошибки сборки.
Вы собираите в BuildRoot. ( там uglibs? )
На этой ситеме сборки основаны все оригинальные BSP производителей плат с устаревшими ядрами.
Ошибок там море. И недоделок то же. По крайней мере 2 года назад так было. Я от неё отказался и написал свою.

BuildRoot очень динамично прогрессирует (возможно те "2 года назад"

) + его используют для сборки своих образов системы очень многие промышленные производители embedded устройств для своих серийных изделий. Так что, в некотором смысле, его можно считать отраслевым стандартом в этой сфере.
Я собирал с BuildRoot разные образы (разного наполнения) и для Orange Pi, и для Rapsberry Py, и x86 под QEMU для последующего переноса на железо. Никаких нигде ошибок и косяков.
Более того, я собирал рабочий образ (Orange Pi, всё с BuildRoot) с Xenomai Mercury (1-ядерная конфигурация, как они называют, без ipipe) ... но это не то что надо, ... но можно писать и выполнять с Xenomai API.
Собирал, обновлял сборку ядра, и с помощью Armbian ... и тоже всё успешно, но без патча ipipe, и в обсуждениях с авторами среды сборки Armbian было сказано (предположено) что выполнять внешние скрипты патченья между фазами сборки не представляется возможным.

Своей системы сборки у меня нет, и писать такую я не собираюсь.

P.S. Кто такой uglibs я не знаю, не соображу. Если вы имеете в виду стандартную C-библиотеку, то там можно на выбор альтернативу указывать.

going писал(а): Вы собрали ядро ipipe и библиотеки Xenomai, а добавившийся функционал в дереве объектов не прописали или прописали не корректно?

Я использовал готовые патчи ipipe от авторов Xenomai.
Использовать GIT исходников ipipe смысла нет, потому как это не добавляет возможности сборки патча под другие версии ядра Linux, кроме тех, которые собрали в Xenomai... как стало понятно здесь в обсуждении выше.
Xenomai настаивают в документации чтобы патченье ядра Linux делалось их скриптом prepare-kernel.sh в дереве исходников Xenomai, который имеет, на минуточку, 453 строк shell-кода патченья.
Когда я применяю этот их проприетарный скрипт патченья ядра (x86) - вся сборка успешная, собирается работоспособная и тестируемая reakrime система.
Когда ipipe подсовывается BuildRoot (указанием в меню конфигурации) как стандартный патч-скрипт для команды patch - вываливаются ошибки при последней фазе сборки дерева исходников проекта Xenomai.
Та же история со сборкой Armbian (по их авторскому мнению) - применить патчи стандартной командой можно, поместив (добавив) патч-скрипт в определённый каталог; выполнять собственный скрипт патченья - нет.

В этом и основной вопрос: если вы делаете успешную сборку системы Xenomai Cobalt, до конца, с установкой Xenomai tools - то патчили ядро Linux патчем ipipe скриптом prepare-kernel.sh от Xenomai, или стандартными средствами Linux?

going · Сообщение **going** » 11 июл 2018, 12:26

Olej писал(а):В этом и основной вопрос: если вы делаете успешную сборку системы Xenomai Cobalt, до конца, с установкой Xenomai tools - то патчили ядро Linux патчем ipipe скриптом prepare-kernel.sh от Xenomai, или стандартными средствами Linux?

Всё же просто.

Код: Выделить всё

cd DIR/xenomai
grep "patch" scripts/prepare-kernel.sh
.... выхлоп grep ......
grep "patch -p1" scripts/prepare-kernel.sh

И всё видно. скрипт проверяет то ли ему подсунули и можно ли это применить, если да то применяет.
Если подсовывать то, что заведомо применяется без ошибок просто одна строчка. В смысле, что речь о каком то ядре и приведения его к виду ipipe

Код: Выделить всё

patch -p1 -f -s < $ipipe_patch

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

going · Сообщение **going** » 11 июл 2018, 12:54

Olej писал(а):Более того, я собирал рабочий образ (Orange Pi, всё с BuildRoot)

Может соберёте Cobalt для этой платы ещё разок в buildroot. Для Вас эта система сборки хорошо известна.
Перед началом выложите сюда ту честь скрипта, начиная с этапа конфигурации ядра,
кусок сборки ядра можно заменить одной фразой "сборка ядра"
затем кусок конфигурации xenomai со всеми определёнными переменными которые передаются скрипту.

Что нибуть подправим.
Затем посмотрим на лог сборки и ошибки, котрые будут. Обсудим. Подправим. И т.д.

going · Сообщение **going** » 11 июл 2018, 13:01

Olej писал(а):для Orange Pi, и для Rapsberry Py, и x86 под QEMU

Эсли не сложно, немного по подробнее для ARM.
Эмуляция ARM системы в QEMU и уже в ней нативная сборка без кросскомпиляции?

Olej · Сообщение **Olej** » 11 июл 2018, 14:40

going писал(а):
Olej писал(а):для Orange Pi, и для Rapsberry Py, и x86 под QEMU
Эсли не сложно, немного по подробнее для ARM.
Эмуляция ARM системы в QEMU и уже в ней нативная сборка без кросскомпиляции?

Про ARM и x86 - это упоминались совершенно разные сборки в совершенно разное время сделанные.
В BuildRoot есть достаточно много предопределённых дефаултных конфигураций "машин", для разных архитектур, которые берутся за основу, чтобы не набирать это руками (потом детали можно подконфигурировать) ... вот малая часть этих дефаултов:

Код: Выделить всё

[olej@xenix buildroot-master]$ make list-defconfigs | grep orangepi
  orangepi_lite_defconfig             - Build for orangepi_lite
  orangepi_one_defconfig              - Build for orangepi_one
  orangepi_pc2_defconfig              - Build for orangepi_pc2
  orangepi_pc_defconfig               - Build for orangepi_pc
  orangepi_pc_plus_defconfig          - Build for orangepi_pc_plus
  orangepi_plus_defconfig             - Build for orangepi_plus
  orangepi_prime_defconfig            - Build for orangepi_prime
  orangepi_win_defconfig              - Build for orangepi_win
  orangepi_zero_defconfig             - Build for orangepi_zero
  orangepi_zero_plus2_defconfig       - Build for orangepi_zero_plus2

Для ARM таких дефаултов великое множество. Сборка под ARM в BuildRoot - кросс-компиляция на x86.
Для x86 у них всего 2 дефаулта: QEMU для 32 бит + QEMU для 64 бит (не хочется сейчас лезть в list-defconfigs, смотреть как они их условно называют) - для отладки они такие образы запускают под QEMU, потом они могут быть откопированы на реальные носители.

Olej · Сообщение **Olej** » 11 июл 2018, 15:08

going писал(а): Всё же просто.
Код: Выделить всё
cd DIR/xenomai
grep "patch" scripts/prepare-kernel.sh
.... выхлоп grep ......
grep "patch -p1" scripts/prepare-kernel.sh
И всё видно. скрипт проверяет то ли ему подсунули и можно ли это применить, если да то применяет.
Если подсовывать то, что заведомо применяется без ошибок просто одна строчка. В смысле, что речь о каком то ядре и приведения его к виду ipipe
Код: Выделить всё
patch -p1 -f -s < $ipipe_patch

А мне кажется, что всё совсем не так просто. Вот по вашему совету:

Код: Выделить всё

[olej@dell scripts]$ grep "patch" prepare-kernel.sh
patch_kernelversion_specific="n"
patch_architecture_specific="n"
patch_kernelversion_filter="b"
patch_architecture_filter="b"
patch_copytempfile() {
    if test "$patch_kernelversion_specific" != "$patch_kernelversion_filter" \
        -a "$patch_architecture_specific" != "$patch_architecture_filter"; then
patch_append() {
    if test "x$output_patch" = "x"; then
            patch_copytempfile "$file"
patch_ed() {
    if test "x$output_patch" = "x"; then
            patch_copytempfile "$file"
patch_link() {
        if test "x$output_patch" = "x" -a -e $linux_tree/$link_dir; then
            if test "x$output_patch" = "x"; then
generate_patch() {
            -e "s,^+++ \.\(/.*\)$,+++ linux-patched\1,"
usage='usage: prepare-kernel --linux=<linux-tree> --ipipe=<ipipe-patch> [--arch=<arch>] [--outpatch=<file> [--filterkvers=y|n] [--filterarch=y|n]] [--forcelink] [--default] [--verbose]'
	ipipe_patch=`echo $1|sed -e 's,^--adeos=\\(.*\\)$,\\1,g'`
	ipipe_patch=`eval "echo $ipipe_patch"`
	ipipe_patch=`echo $1|sed -e 's,^--ipipe=\\(.*\\)$,\\1,g'`
	ipipe_patch=`eval "echo $ipipe_patch"`
    --outpatch=*)
	output_patch=`echo $1|sed -e 's,^--outpatch=\\(.*\\)$,\\1,g'`
        patch_kernelversion_filter=`echo $1|sed -e 's,^--filterkvers=\\(.*\\)$,\\1,g'`
        patch_architecture_filter=`echo $1|sed -e 's,^--filterarch=\\(.*\\)$,\\1,g'`
# Create an empty output patch file, and initialize the temporary tree.
if test "x$output_patch" != "x"; then
    patchdir=`dirname $output_patch`
    patchdir=`cd $patchdir && pwd`
    output_patch=$patchdir/`basename $output_patch`
    echo > "$output_patch"
       echo "I-pipe found - bypassing patch."
   while test x$ipipe_patch = x; do
      echo -n "I-pipe patch: "
      read ipipe_patch
      if test \! -r "$ipipe_patch" -o x$ipipe_patch = x; then
         echo "$me: cannot read I-pipe patch from $ipipe_patch" >&2
         ipipe_patch=
   patchdir=`dirname $ipipe_patch`; 
   patchdir=`cd $patchdir && pwd`
   ipipe_patch=$patchdir/`basename $ipipe_patch`
   cd $linux_tree && patch --dry-run -p1 -f < $ipipe_patch || { 
        echo "$me: Unable to patch kernel $linux_version$linux_EXTRAVERSION with `basename $ipipe_patch`." >&2
   patch -p1 -f -s < $ipipe_patch
patch_kernelversion_specific="y"
    patch_architecture_specific="y"
            patch_append init/Kconfig
	(echo; echo $p) | patch_append arch/$linux_arch/Makefile
	echo $p | patch_append arch/$linux_arch/Makefile
    patch_architecture_specific="n"
	( echo ; echo $p ) | patch_append drivers/Makefile
	( echo ; echo $p ) | patch_append kernel/Makefile
patch_kernelversion_specific="n"
patch_architecture_specific="y"
patch_link r m kernel/cobalt/arch/$linux_arch arch/$linux_arch/xenomai
patch_link n n kernel/cobalt/include/ipipe arch/$linux_arch/include/ipipe
patch_architecture_specific="n"
patch_link n m kernel/cobalt kernel/xenomai
patch_link n cobalt-core.h kernel/cobalt/trace include/trace/events
patch_link n cobalt-rtdm.h kernel/cobalt/trace include/trace/events
patch_link n cobalt-posix.h kernel/cobalt/trace include/trace/events
patch_link r n kernel/cobalt/include/asm-generic/xenomai include/asm-generic/xenomai
patch_link r n kernel/cobalt/include/linux/xenomai include/linux/xenomai
patch_link n m kernel/cobalt/posix kernel/xenomai/posix
patch_link n m kernel/cobalt/rtdm kernel/xenomai/rtdm
patch_link r m kernel/drivers drivers/xenomai
patch_link n n include/cobalt/kernel include/xenomai/cobalt/kernel
patch_link r n include/cobalt/kernel/rtdm include/xenomai/rtdm
patch_link r n include/cobalt/uapi include/xenomai/cobalt/uapi
patch_link r n include/rtdm/uapi include/xenomai/rtdm/uapi
patch_link n version.h include/xenomai include/xenomai
if test "x$output_patch" != "x"; then
    echo 'Generating patch.'
    generate_patch > "$output_patch"

Я не разбирался (пока) что там в деталях делает prepare-kernel.sh в 500 строк, но даже здесь видно, что делается множество линков ... каким-то образом вовлекается имя оригинального проекта --adeos ... который они тщательно стараются нигде не упоминать и везде его подменяют на ipipe ...
Одних понаделанных линков в дереве kernel & include - достаточно для того, чтобы потом дерево исходников Xenomai не собиралось!

P.S. Т.е. ... утилита patch, как оборотная сторона медали diff может внести любые изменения в коды существующих файлов, но diff не знает, а patch вослед - не могут поменять структуру дерева файлов, доделать множество линков. Вот эту дополнительную работу, похоже, они и заложили в скрипт prepare-kernel.sh.

going · Сообщение **going** » 11 июл 2018, 17:04

Olej писал(а):..... видно, что делается множество линков ... в дереве kernel & include
P.S. Т.е. ... утилита patch, как оборотная сторона медали diff может внести любые изменения в коды существующих файлов, но diff не знает, а patch вослед - не могут поменять структуру дерева файлов, доделать множество линков. Вот эту дополнительную работу, похоже, они и заложили в скрипт prepare-kernel.sh.

Да всё хитро. Три скрипта bootstrap, prepare-kernel.sh, configure.
Почему именно так, я не знаю, но могу предположит, что этоти скрипты сложились эволюционно,
в процессе применения их для разных архитектур, компиляторов, хостов сборки, библиотек, версий ядра.
configure пытается, подчеркну пытается, определить на какой системе и архитектуре он трудится, для какой ахитектуры собирает,
проверяет кросскомпилятор, пытается его тестить с разными параметрами применяя для сборки тестового файлика и фиксируя код завершения,
проверяет доступные из кросскомпилятора библиотеки и заголовки к ним и т.д. и напоследок собирает.
prepare-kernel.sh проверяет наличие кода ipipe в ядре может применить патч, проверив применяемость, создаёт кучу линков на заголовочные файлы.
Необходимые для компиляции ядра.
Всё это видно в логе в каталоге где собирается xenomai
У меня последняя строчка лога:
8584 configure: exit 0

Итог. Проще определить чего они хотят сожрать, в какой последовательности и дать и дать им это.

Разговор до этого шёл только о наложении патчей. Повторю нет разницы между тремя вариантами:
1) Использовать git ipipe - патч не нужен.
2) Применить самому патч к источникам ядра - утилита patch
3) Подсунуть патч скрипту prepare-kernel.sh
Но во всех случаях применение скрипта необходимо.

P.S. Просто покажите кусок скрипта сборки.

donvictorio · Сообщение **donvictorio** » 12 июл 2018, 00:54

a linuxcnc умеет работать с xenomai ядром?

going · Сообщение **going** » 12 июл 2018, 06:00

donvictorio писал(а):a linuxcnc умеет работать с xenomai ядром?

Да. Прекрасно. При сборке LinuxCNC надо ему об этом сказать, какое будет ядро.
Т.е. РТ ядро (rtai, RTPREEMPT, Xenomai) будет в зависимостях пакета LinuxCNC.
Они связаны.

Olej · Сообщение **Olej** » 12 июл 2018, 14:14

going писал(а):
donvictorio писал(а):a linuxcnc умеет работать с xenomai ядром?
Да. Прекрасно. При сборке LinuxCNC надо ему об этом сказать, какое будет ядро.
Т.е. РТ ядро (rtai, RTPREEMPT, Xenomai) будет в зависимостях пакета LinuxCNC.
Они связаны.

RTPREEMPT и Xenomai могут использоваться одновременно ... для пущего коммулятивного эффекта

.
Это есть в документации по Xenomai.
Про RTAI ничего не могу сказать, но в описаниях пишут, что Xenomai есть развитие RTAI, ответвившееся от него в какой-то момент времени.

cnc-club.ru

Xenomai + LinuxCNC, EVL + LinuxCNC из исходников

Re: Xenomai + LinuxCNC из исходников -> x86, x86_64, arm, ar

Re: Xenomai + LinuxCNC из исходников -> x86, x86_64, arm, ar

Re: Xenomai + LinuxCNC из исходников -> x86, x86_64, arm, ar

Re: Xenomai + LinuxCNC из исходников -> x86, x86_64, arm, ar

Re: Xenomai + LinuxCNC из исходников -> x86, x86_64, arm, ar

Re: Xenomai + LinuxCNC из исходников -> x86, x86_64, arm, ar

Re: Xenomai + LinuxCNC из исходников -> x86, x86_64, arm, ar

Re: Xenomai + LinuxCNC из исходников -> x86, x86_64, arm, ar

Re: Xenomai + LinuxCNC из исходников -> x86, x86_64, arm, ar

Re: Xenomai + LinuxCNC из исходников -> x86, x86_64, arm, ar

Re: Xenomai + LinuxCNC из исходников -> x86, x86_64, arm, ar

Re: Xenomai + LinuxCNC из исходников -> x86, x86_64, arm, ar

Re: Xenomai + LinuxCNC из исходников -> x86, x86_64, arm, ar

Re: Xenomai + LinuxCNC из исходников -> x86, x86_64, arm, ar

Re: Xenomai + LinuxCNC из исходников -> x86, x86_64, arm, ar

Re: Xenomai + LinuxCNC из исходников -> x86, x86_64, arm, ar

Re: Xenomai + LinuxCNC из исходников -> x86, x86_64, arm, ar

Re: Xenomai + LinuxCNC из исходников -> x86, x86_64, arm, ar

Re: Xenomai + LinuxCNC из исходников -> x86, x86_64, arm, ar

Re: Xenomai + LinuxCNC из исходников -> x86, x86_64, arm, ar