Ads
Comments 31
+21
Крайне неожиданно видеть женский род в прошедшем времени в статьях про Linux. Но, здорово. Так держать.
+7
Лучше бы по сути что-нибудь написали, статья то на черезвычайно редкую тему, материал на вес золота.
Я прямо сейчас не могу читать к сожалению, пометил на будущее
+5
Спасибо, крайне интересно.
Очень напоминает книгу «Недокументированные возможности Win 2k» Свена Шрайбера.
Она была кладезем информации в свое время.
UFO landed and left these words here
UFO landed and left these words here
+1
Да, ещё: ну почему они называются 'bottom' и 'top'? (Я про прерывания) Я всё время путаюсь, какой из них «настоящий», а какой softirq.
+3
почему они называются 'bottom' и 'top'

Подозреваю, что это связано с текущим уровнем запрета прерываний: если уровень высокий (прерывания запрещены) — это top half, если уровень низкий (прерывания разрешены) — это bottom half.

Я всё время путаюсь, какой из них «настоящий», а какой softirq

В ядре есть примитивы синхронизации со словом _bh (spin_lock_bh, например), но нет ни одного со словом _th, вместо этого используется _irq (spin_lock_irq, например).
+2
По поводу происхождения названия bottom half, вроде история была такая, что механизм отложенной обработки под изначальным названием softirq (тогда еще не было tasklet'ов) первым решил преминуть Теодор Тсо, а Линус заявил что не примет в ядро то, что имеет название softirq, поэтому Тед решил назвать механизм отложенной обработки иначе и придумал термины top и bottom, в соответствии с логикой которую Вы описали выше.
+5
Выше уже предложили версию, но у меня есть подозрение, что все проще.
Когда мы говорим про верх и низ страницы, мы говорим top и bottom. Если представить, что мы функцию поделим на две части, то верхняя, что будет исполняться раньше, — это top, а нижняя — bottom.
+4
Объяснение выше мне понравилось, ваше — нет. Потому что исходя из «low level details» чем ближе к железу, тем ниже, то есть обработчик «самого важного» должен быть bottom-half.
+3
Как же так, топик про tasklet-ы в ядре Linux, а здесь забыли упомянуть эпичную фразу про «плохую водку» из документации %)
The name 'tasklet' is misleading: they have nothing to do with 'tasks', and probably more to do with some bad vodka Alexey Kuznetsov had at the time.


Вообще документация к ядру меня в своё время очень порадовала, написано людьми для людей.
+2
В разделе Tasklet, в тегэ abbr (наведите на слово tasklet, подчеркнутое и выделенное полужирным).
+6
На самом деле не забыли, если вы наведете на слово tasklet, то во всплывающей подсказке увидите именно эту цитату. Своего рода пасхалка :)

Читать ядро Linux и правда очень приятно.
+1
Код ядра во многих местах пасхалка. Когда переписывал драйвер одной сетевой железки с 1.х на 2.х прямо плакал от того, что коду-то подевались смешные комменты, веселые локальные переменные. Мне кажется именно тогда, процент форфан дядь начал разбавляться корпоративными профи. Так что колическтво веселых пасхалок начало падать, и заменяться скрытыми бэкдорами.
0
А что там подробнее — смотрите на секюрити патчи. Затронутый исходный код иногда выглядит подозрительно. Как-то за пивом был спор о статических анализаторах — тогда и наслушался о подобных случаях.
0
Впервые слышу о намеках, что «корпоративные профи» (а не какой-то там NSA) делают бэкдоры в коде Linux'а, поэтому и спросил, может есть ссылки что кого-то конкретно «поймали».
0
Я с 2001 не интересуюсь этой темой. Но в драйвере синхронного ван адаптера одной российской фирмы не было проверок поступающих данных как класса. То есть с другой стороны можно было сформировать не правильный поток и взломать систему. Не думаю, что это было сделано специально — но…
-1
spinlock (крутящуюся блокировку)
И вокруг чего она крутится? :-) Это всё же циклическая блокировка. Как вариант — взаимная блокировка.
+3
вокруг чего она крутится

Вокруг проверки условия, что текущему процессору можно выполнять свою работу.

Как вариант — взаимная блокировка.

Взаимная блокировка (deadlock) — это совсем другая ситуация.
0
Если погуглить, то такой перевод тоже встречается, по-моему, именно его я впервые в университете и услышала.
Но укажу тогда в скобочках и этот вариант, раз вопросы возникают.
+2
В этом контексте разрешены аппаратные прерывания, которые вытесняют tasklet’ы на время исполнения ISR

Как они вытесняются, если у них нет стека и контекста? Или имеется ввиду работа «между» тасклетами?
+3
Аппаратные прерывания асинхронны, они могут произойти в любой момент, в том числе в середине tasklet'а, и ISR, соответственно, обрабатывается сразу же.
Своего собственного стека у них нет, но на каком-то стеке они все же должны исполняться, так что после обработки ISR есть, какой контекст восстанавливать. В Linux (как минимум в x86), например, перед началом обработки softirq происходит переключение на специально выделенный стек.
+6
Отлично написано, спасибо. «Ядро Linux. Описание процесса разработки» Р. Лава помогает разобраться с темой.
На мой взгляд, стоит также упомянуть о том, что минимальная необходимая логика внутри обработчика в top-half должна содержать ответ устройству о полученном прерывании, это must have всегда.
+3
минимальная необходимая логика внутри обработчика в top-half должна содержать ответ устройству о полученном прерывании, это must have всегда

Правильнее было бы сказать, что top half должен либо заблокировать, либо очистить IRQ от устройства, чтобы не быть вызванным повторно после разрешения прерываний после возврата из ISR. Как именно это будет сделано — зависит от устройства. Кроме того, при использовании threaded-обработчиков прерываний даже этого можно не делать явно: threaded-часть обработчика будет выполняться с заблокированным IRQ автоматически.
0
Спасибо за комментарии, это и подразумевалось под
как-то взаимодействует с аппаратурой

В статье уточнила.
0
Пару интересных моментов всё же в цикле статей не учли. Какие методы вызова softirq есть в Linux, что делает ksoftirqd и чем отличаются обычные обработчики прерываний от threaded irq, а также очень тонкий момент высвобождения ресурсов прерывания и tasklet'а при их использовании в коде.
Only those users with full accounts are able to leave comments.  , please.