to post messages and comments.

Мне вот любопытно — а нафига Линус подписывает мелкие безсмысленные изменения в API? Вот в 4.9 — get_user_pages и ttm_bo_move_memcpy, которые менялись в 4.6 и 4.8. Изменения — откровенно шыло на мыло, век бы их не видеть, сделать новое имя и #define для старого — три строчки, документацыи разумеется никакой — как хипстерское говно со словом "рефакторинг" вообще можно пускать в какой-то серьёзный проект?!?

>> Unpacking linux-4.9.tar.xz to /var/tmp/portage/sys-kernel/gentoo-sources-4.9.8/work * Excluding Patch #5000_enable-additional-cpu-optimizations-for-gcc.patch ... [ ok ]
* Failed to dry-run patch genpatches-4.9-10.base.tar.patch
* Please attach /var/tmp/portage/sys-kernel/gentoo-sources-4.9.8/temp/genpatches-4.9-10.base.tar.err to any bug you may post.
* ERROR: sys-kernel/gentoo-sources-4.9.8::gentoo failed (unpack phase):
* Unable to dry-run patch on any patch depth lower than 5.

решил попробовать 4.9 (4.9.4-4.9.5) собралось и запустилось, но драйвера snd_usb_toneport и snd_usb_line6 отказались работать напрочь, dmesg показывал ошибки драйвера. Пришлось на 4.8.17 вернуться

Ведро пинусов 4.7 (ну, на самом деле не знаю, с какого точно) при монтировании fat добавляет опцыю utf8. Дажэ если там до того прописан iocharset=. Ненависть.
Не то, чтобы добавить utf8=0 было так сложно. Но, блин, нафига они ломают работавшэе?

Использование pf_ring на MIPS жрёт порядка 200 мегабит при софтварном роутинге. При этом загрузка CPU далека от максимума, что интересно. Думаем, что делать, то ли писать свой kernel bypassing на mmaped raw socket, то ли делать полностью кодогенерированный модуль и втаскивать его в ядро, то ли прикрутить какой-нибудь хак типа копирования пакетов в какой-нибудь фейковый интерфейс из нужных хуков нетфильтра и навешивание pf_ring уже на него.

Сегодня в lkml случайно увидел, что кто-то патчит и поддержывает драйвер plip. Я, в принцыпе, рад, но чудны дела твои, софтиндустри.

PS Я как-то пытался лет почти 20 назад этим пользоваться. Оно было дажэ в общем юзабельно, только в общем обладало всеми недостатками SLIP при дальности передачи в два метра. Безсмысленно как-то.

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

<<There's a different issue with freeing of mutexes, which is not a bug,
but "by design". Namely that mutexes aren't truly "atomic". They are
complex data structures, and they have issues that a spinlock does not
have.

When unlocking a mutex, the thread doing the unlocking will still
touch the mutex itself after another thread could already have
successfully acquired the mutex. This is not a problem in any normal
use. since all of this is perfectly coherent in general, but it means
that code sequences like:

mutex_lock(mem->mutex);
kill_it = !--mem->refcount;
mutex_unlock(mem->mutex);
if (kill_it)
free(mem);

are fundamentally buggy.

Note that if you think of mutexes as truly indivisible atomic
operations, the above is "obviously correct": the last person who got
the mutex marked it for killing. But the fact is, the next-to-last
mutex acquirer may still actively be in the non-indivisible
mutex_unlock() when the last person frees it, resulting in a
use-after-free. And yes, we've had this bug, and as far as I know it's
possible that the RT code introduces this bug when it changes
spinlocks into mutexes. Because we do exactly the above code sequence
with spinlocks. So just replacing spinlocks with mutexes is a very
subtly buggy thing to do in general.
>
from Linus Torvalds lkml.org

Периодически у меня домашняя венда 7 падает в BSOD при попытке уйти в sleep. Причём в дампе явное указание на сетевой стек, на вершине которого находится фильтр от VMWare(длительная обработка Power Irp). Для меня очевидно, что бага может быть и не в VMWare, поэтому сегодня я целый день сижу за домашним компом со включённым verifier'ом на все дрова в системе. Укладывал машину спать раз 20 — хуй, не падает и засыпает, а потом просыпается. Я знаю, что если я выключу verifier, то после ребута машина обязательно упадёт в BSOD при попытке заснуть. Наблюдающий всегда влияет на наблюдаемую систему. От така хуйня, маляты.

Ну конечно же. Хочешь книжек по гипервизорам? Вот тебе книжки: "как настроить kvm/xen/vmware/хуё-моё и быть щасливым тупицей". Хочешь разобраться как оно работает? Вот тебе неебические сорцы и мануалы. Ну, слава богу, не нужно в дизасм запихивать. Причем девелоперские форуме intel/amd — такое адовое говно, что хочется плакать. Там иногда чуваки задают вопросы, типа:

— а как включить EPT?
— тыры-пыры, типа так и так, надо это проверить и т.п.
— ай, блять, мне нужно было включить Nx, я перепутал.

/facepalm

В общем возможно глупый вопрос. Но есть ядро надо запустить его на железке. В параметрах ядра обычно указывают имя консоли, ну например ttyPSC0, но бывают и другие варианты ttyS0 и т.д. Как узнать какой именно вариант в моем случае. Я так понимаю это зависит от драйвера? Но как это посмотреть?

Объяснял в каментах почему в Windows mutex в UM, а mutant в KM. История действительно забавная.

"The name mutant has a colorful history. Early in Windows NT's development, Dave Cutler created a kernel mutex object that implemented low-level mutual exclusion. Later he discovered that OS/2 required a version of the mutual exclusion semaphore with additional semantics, which Dave considered "brain-damaged" and which was incompatible with the original object. (Specifically, a thread could abandon the object and leave it inaccessible.) So he created an OS/2 version of the mutex and gave it the name mutant. Later Dave modified the mutant object to remove the OS/2 semantics, allowing the Win32 subsystem to use the object. The Win32 API calls the modified object mutex, but the native services retain the name mutant."

blogs.msdn.com

Как же меня бесит кодить одновременно под ядро и под юзермод. Под ядро всё так аккуратно, красиво, кодишь функционал, а в UM библиотека к ядерному функционалу превращается в какие-то фабрики-хуябрики, виртуальные функции и прочую хуиту.

Написал получение размера кэша данных L1 для ARMv7. Большая часть на армовом ассемблере. Чувствую себя непобедимым. Проверил на Exynos5, надеюсь будет работать и на чём-нить другом :).

Оффсеты стащил у WindRiver : marc.info , но целый день читать datasheets and whitepapers всё равно пришлось.

Из срача, сопровождавшего патч в linux-arm-kernel вытащил волшебное определение:
"Pointless. Useless. Stupid. And unnecessarily complex for no reason what so ever".

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

# Когда область грязных страниц заполнится на этот процент начать сброс буферов
vm.dirty_background_ratio = 50
# Такой процент системной памяти может быть использован под грязные страницы
vm.dirty_ratio = 80
# После данного времени, в сотых секунды осуществляется сброс на диск. По умолчанию 3000.
vm.dirty_expire_centisecs = 360000

Источники:
docs.neo4j.org
kernel.org

Столкнулся тут со странной "фичей" ядра
CONFIG_SCHED_AUTOGROUP
оно автоматически раскидывает процессы по группам планировщика на основании сессий. На первый взлдяд логично ее включить, но выясняется, что это приводит к тому, что emerge, запущенный в найсе 19 оказывается в своей собственной группе планирования (ибо другой пользователь) и умудряется выталкивать пользовательские процессы с более низким найсом 0. В целом все выглядит так, будто найс учитывается только в пределах группы процессов, а между группами время процессора делится поровну, вобщем, я решил это выключить. Выключить можно и динамически
sysctl kernel.sched_autogroup_enabled = 0

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

Судя по исходникам, лок на цгруппах не стоит:
lxr.free-electrons.com

Судя по выводу ps процесс вполне обычный, но модификация цгрппы через echo $$ > /sys/fs/cgroup/foo/bar/task приводит к invalid argument. замена $$ на 0, тоже не помогает.

Куда можно копать?

P.S. (последний тег, чтобы больше народу скастовать).
P.P.S. я знаю как обойти этот вопрос запустив демона в userspace, но мне не нравится такой вариант.

Вопрос на понимание sharedsubtree. Сколько маунтов будет создано в результате следующего набора команд?
mount -t tmpfs --make-shared test test
for i in `seq 10`; do mount --bind test test; done
cat /proc/self/mountinfo | grep test | wc -l

Вот зачем посылка сигнала группе заканчивается успехом, когда сигнал доставлен не всем
commit 3a948de76cd625264c6fbea172a51cf5d76cd12b
Author: Linus Torvalds <[email protected]>
Date: Thu Jun 17 18:23:45 2004 -0700

Fix kill_pg_info(): return success if any signal succeeded.

Сегодня получил левелап. :) Пару дней назад поднял на своём домашнем проксмоксе VZ контейнер с дебианом, поставил средства разработки, склонировал с гитхаба исходники ядра для AllWinner платформы и при помощи кросскомпиляции собрал таки модуль ядра под планшет. Правда пришлось в паре мест поправить Makefile и .config, а полученные в результате компиляции модули допиливать в одном месте в хекс редакторе руками, но оно — таки заработало! Собирал ftdi_sio для того, чтобы подключить к планшетнику arduino nano.

Вывод dmesg:
<6>[38995.640000] ftdi_sio 1-1:1.0: FTDI USB Serial Device converter detected
<6>[38995.670000] usb 1-1: Detected FT232RL
<6>[38995.670000] usb 1-1: Number of endpoints 2
<6>[38995.670000] usb 1-1: Endpoint 1 MaxPacketSize 64
<6>[38995.680000] usb 1-1: Endpoint 2 MaxPacketSize 64
<6>[38995.680000] usb 1-1: Setting MaxPacketSize 64
<6>[38995.690000] usb 1-1: FTDI USB Serial Device converter now attached to ttyUSB0

Плюс на том же планшетнике стоит Linux Deploy и под ним работает debian stable. Теперь можно будет рулить девайсами, подключенными к юсб хосту прямо из него, а это открывает такой простор для прочих забав... Например, можно поставить полноценную версию python, gcc для AVR или ещё чего-нибудь, поставить vim со всеми момими конфигами и плагинами и разрабатывать прямо на планшете, цепляясь к нему по ssh.

P.S.: Да, я знаю, что я задрот, но я счастлив.
P.P.S.: Теперь ещё к нему можно собрать модуль для подключения по BT джойстика от SPS3. :))