Интеграция изменений в ядро ​​с помощью Yocto с помощью патчей

Если вы хотите изменить ядро ​​Linux таким образом, чтобы оно исключало определенные модули, вы обычно переходите к /kernel/msm-4.9/arch/arm/configs/vendor/<machine-name>_defconfig, в котором есть набор символов Kconfig, а те, которые я хочу исключить, закомментированы, как показано ниже.

CONFIG_PPP=y
#CONFIG_PPPOL2TP=y
CONFIG_PPP_ASYNC=y

Затем я создаю образ Linux, запуская bitbake virtual/kernel, в который в идеале должны быть интегрированы мои изменения, но когда я загружаю образ, я все еще вижу некоторые из журналов комментируемого модуля.

Я проверил документацию по yocto и похоже, что они создают патч файла, который хотят изменить, а затем добавляют этот измененный файл в файл .bbappend, например:

 FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"

 SRC_URI += "file://0001-calibrate-Add-printk-example.patch"

Итак, в моем случае, если бы я изменил /kernel/msm-4.9/arch/arm/configs/vendor/<machine-name>_defconfig, я бы:

  • создать копию этого исходного файла
  • вставьте его в poky/meta-bsp/recipes-kernel/linux-msm/files
  • переименовать его
  • включить этот файл в .bbappend (как показано выше)

Но как указанный выше патч переопределит исходный /kernel/msm-4.9/arch/arm/configs/vendor/<machine-name>_defconfig, который я планировал изменить с помощью этого подхода?


yocto bitbake linux-kernel embedded-linux
person Jazzy    schedule 12.01.2021    source источник
comment
Прежде всего, правильное отключение опции будет # CONFIG_PPPOL2TP is not set (именно так, как я написал, включая все пробелы и т. д.). То, что вы сделали со своим комментарием, переключилось на то, что по умолчанию.   -  person 0andriy    schedule 14.01.2021
comment
Я считаю, что это не должно иметь значения, поскольку # просто относится к комментарию, а все, что следует за #, не имеет значения, не так ли? Кроме того, файл .config, сгенерированный в poky, имеет # CONFIG_PPPOL2TP is not set, поэтому я предполагаю, что система сборки просматривает то, что было закомментировано в соответствующих файлах defconfig, и гарантирует, что это не включено в образ ядра. Кроме того, запуск rebake virtual/kernel помог, но я все еще не уверен, как использовать патч для достижения аналогичной задачи...   -  person Jazzy    schedule 14.01.2021
comment
Нет. Система сборки не смотрит на комментарии, она их просто игнорирует. А затем применяется по умолчанию, каким бы оно ни было. В вашем конкретном случае это означает отключить, во многих других это может быть что-то другое. В конфигурации есть три состояния: а) включено (как «y» или «m»), б) отключено (поскольку «#... не задано» или в) игнорируется как комментарий или неразборчивый мусор (означает значение по умолчанию на эта конкретная конфигурация).   -  person 0andriy    schedule 14.01.2021
comment
Если использование # игнорирует их, почему добавление is not set может быть полезным вместо того, чтобы просто закомментировать его с помощью #?   -  person Jazzy    schedule 14.01.2021
comment
Прочитайте мои комментарии еще раз. Если что-то понятно, читайте документацию.   -  person 0andriy    schedule 14.01.2021

Ответы (1)


arrow_upward
0
arrow_downward

Вы правы, модификации исходников делаются с помощью патчей в Yocto. Отвечая на ваш вопрос

Но как указанный выше патч переопределит исходный файл /kernel/msm-4.9/arch/arm/configs/vendor/_defconfig, который я планировал изменить с помощью этого подхода?

это делается автоматически :)

То есть система сборки (bitbake) автоматически обнаруживает файлы с расширением .patch среди содержимого SRC_URI, копирует эти файлы из каталога meta-layer в каталог сборки где-то под build/tmp/work/... и автоматически применяет тысячи исправлений к исходному коду (каталог с исходным кодом определен по переменной S в рецепте).

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

Одна из основных идей Yocto — воспроизводимые и расширяемые сборки. Это означает, что все метаданные разбиты на разные репозитории (то есть layers), которые поддерживаются разными командами. В основном команды не имеют доступа к репозиториям друг друга, и никто не имеет доступа к исходному коду какого-либо внешнего проекта (kernel в вашем случае). Конечно, всего этого можно создать git-fork, но это намного сложнее, чем писать метаданные. Вот почему Yocto был создан — чтобы взять внешние метаданные (например, слой poky), исходный код («ядро») и заставить его работать, написав только свои метаданные (ваш собственный слой), без каких-либо git-fork.

Таким образом, добавление вашего патча и .bbappend в слой poky не имеет смысла, потому что вы не сможете закоммитить слой poky и раздать его своим клиентам - слой poky принадлежит не вам) Однако вы можете создать git-fork, но это усложняет процесс распределения.

Вот почему правильный способ:

  • создайте собственный BSP-уровень
  • создайте .bbappend в своем слое
  • добавить патч к ядру на вашем уровне (на самом деле правильный способ - использовать файлы .scc, поставь патч и пойдет)

Это сделает вашу сборку

  • воспроизводимый - повторная компиляция ядра или даже свежий клон Yocto с вашим BSP-слоем сможет создать то же самое ядро
  • распространяемый (расширяемый) - клиентам нужен только ваш BSP-уровень, другие материалы Yocto можно найти в Интернете.

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

  1. очистить все содержимое ядра, которое у вас есть bitbake -c cleansstate virtual/kernel
  2. получить исходники ядра (клон и патч) bitbake -c patch virtual/kernel
  3. обрабатывать вручную все, что вам нужно в исходных кодах ядра, найденных где-то в рабочих материалах, таких как <TOPDIR>/build/tmp/work/<machine-name>-poky-linux-gnueabi/linux-yocto/<version>/git
  4. собрать ядро ​​bitbake -c package virtual/kernel (клонирование и исправление будут пропущены, так как bitbake помнит, что эти задачи выполнены; артефакты сборки ядра не будут удалены, потому что задача rm_work идет после package, а содержимое ядра на самом деле никогда не удаляется)

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

Чтобы легко собрать ядро ​​вручную (не через bitbake), вы можете запустить скрипт <TOPDIR>/build/tmp/work/<machine-name>-poky-linux-gnueabi/linux-yocto/<version>/temp/run.do_compile

person jango    schedule 20.01.2021
comment
спасибо за подробный ответ. Я был на полпути, когда я узнал о том, что не нужно создавать метаслой под poky, но пример, который я привел в описании, действительно создает слой внутри poky. Если не poky, то где должен быть создан метаслой? слой meta-bsp в моем случае находится внутри poky - person Jazzy; 21.01.2021
comment
хм... возможно, я вас неправильно понял, извините) здесь говорят, что вы создаете свой собственный слой. Если вы прошли этот пункт, то все идет по инструкции. - person jango; 21.01.2021
comment
Да, извините, у меня есть немного более настроенный рабочий каталог Yocto (в вашем случае он называется poky, в моем случае дерево каталогов выглядит иначе), поэтому я вас неправильно понял. Похоже, вы все делаете правильно!)) Ваш meta-bsp должен быть вашим каталогом с вашим пользовательским слоем. Также по вашей ссылке вы можете использовать старую версию (2.2.1). Последняя версия Yocto — 3.2.1, проверьте. - person jango; 21.01.2021
comment
хм, поэтому мы все еще модифицируем исходный файл, а затем создаем/добавляем патч в файл bbappend, который указывает Yocto включить наше изменение. Я представлял себе, что идея будет больше похожа на создание нового файла (копию оригинала) и его изменение, чтобы мы всегда могли вернуться к более старым версиям, не так ли? - person Jazzy; 22.01.2021
comment
или, может быть, я упускаю из виду концепции патчей. Вы можете просто изменить исходный файл и пересобрать образ без создания патча и всего того хорошего, о чем говорится в документации yocto... - person Jazzy; 22.01.2021
comment
Ну да, наконец, мы создаем патч и модифицируем файл с помощью этого патча. То, как вы на самом деле создаете патч, не имеет значения - вы можете git-clone вручную git-clone скинуть исходники в какую-то отдельную папку и создать там патч. Или вы можете просто скачать патч откуда-то. Попробуйте открыть патч - это просто диф текста, не более того. А если вы хотите откатить старые ревизии, просто отключите патч (исключите файл патча из SRC_URI например). - person jango; 22.01.2021
comment
Также вы можете попробовать сделать это как оптимизацию - вместо того, чтобы хранить две версии файла (исходную и измененную), у вас есть оригинал и некоторая модификация, которую нужно применить к оригиналу для создания модифицированного. Очень похоже на git, но git гораздо более сложный инструмент. - person jango; 22.01.2021