Причём функция преобразования доступна, вот я рассказывал здесь: habrahabr.ru/post/252453 (см. главу Бонусы). И предложенное мной исправление в этом же состояло. :-)
Заметил, что вы в драйвере используете dmam_alloc_coherent(), но при этом всё остальное не из devres API. Я писал о нём статью: habrahabr.ru/post/255459.
Процитирую Borislav'а: …even if we build the string properly, we choke later in get_builtin_firmware().
А так похоже, что это хорошее объяснение поведения sprintf().
Кстати, Intel продвигает Intel® Processor Trace, которая при помощи Trace Hub позволит обойтись без этих баснословно стоящих устройств, если я правильно понимаю.
Отличный вопрос! На самом деле помимо разрозненных девелоперских тестов и тестов различных команд / подсистем (например, mmtests) существует проект 0-day kernel test. Подробнее можно почитать здесь: lwn.net/Articles/514278.
В upstream только минимум, необходимый для запуска консоли. См. вот этот пост. Остальное вывалено в кучу в архиве с исходниками где-то на сайте intel.com.
Я подозреваю, что всё, что угодно, воспринимающее U-Boot.
Не пробовал 64-битные ядра, но
Изучаем флаги :)
# grep -c -w lm /proc/cpuinfo
2
U-Boot, ядро Linux, …
U-Boot.
На родной прошивке видно как /dev/mmcblk.
Это продолжение предыдущего вопроса? Иначе не совсем понятно, о чём речь.
К сожалению драйвера последовательных шин на сегодня доступны лишь в Yocto kernel. Работа идёт по претворению их в upstream.
Отвечая на второй вопрос могу лишь порекомендовать пробовать Yocto (сам я его ни разу не пробовал, поэтому за стабильность не ручаюсь).
Ой бяда, английский в вашем commit message хромает. Ну ничего, сам такой :)
Теперь по сути.
Хорошо латать дыры первым попавшимся методом или плохо? Мне кажется что плохо, сам процесс внесения изменений в ядро выглядит, как какая-то гонка, кто успел тот и внес изменения, а последствия, потом разберемся. Мне кажется, что таких исправлений в ядро попадает слишком много, что еще больше запутывает и так не простой код.
Дело в том, что изменения вносятся в основном «тусовкой». Если вы — человек со стороны, а я так вижу по вашим 3 изменениям, то порог входа будет не быстр, а ошибки устранять надо. Ну, и ваш выбор подсистемы tty — одной из самых старейших, конечно, вносит свои проблемы. Кстати, помните, что именно эта подсистема держала kernel global lock в ядре и только относительно недавно была исправлена. Т.е. я хочу сказать, что код там очень древний и очень запутанный.
Первая версия была в августе 2011 :-). Подсистема SCSI — самая консервативная в ядре. Туда удаётся пробить патчи, правда. Но это сопряжено с бешеными трудностями, так что это hard path. Вы посмотрите лучше на мой патч как образец и изменения (всё уходит в одну строку), и его оформления (поле темы, тело письма), а затем найдите что-нибудь в drivers/staging. Не зря же я про staging писал. Грег очень лояльный мейнтейнер, только обязательно проверяйте изменения перед оправкой как минимум компилированием и checkpatch.pl, иначе рассердите его!
DRM_DEBUG_*реализованы как я описывал, черезdmam_alloc_coherent(), но при этом всё остальное не из devres API. Я писал о нём статью: habrahabr.ru/post/255459.А так похоже, что это хорошее объяснение поведения
sprintf().sprintf.2
Отвечая на второй вопрос могу лишь порекомендовать пробовать Yocto (сам я его ни разу не пробовал, поэтому за стабильность не ручаюсь).
Теперь по сути.
Дело в том, что изменения вносятся в основном «тусовкой». Если вы — человек со стороны, а я так вижу по вашим 3 изменениям, то порог входа будет не быстр, а ошибки устранять надо. Ну, и ваш выбор подсистемы tty — одной из самых старейших, конечно, вносит свои проблемы. Кстати, помните, что именно эта подсистема держала kernel global lock в ядре и только относительно недавно была исправлена. Т.е. я хочу сказать, что код там очень древний и очень запутанный.