jcmvbkbc

Как выучить язык ассемблера?

Читать ассемблерный код. Когда научишься с лёгкостью читать, писать тоже сможешь.

Посоветуйте какие-нибудь ресурсы по изучению

Исходники на ассемблере, которые любой компилятор тебе нагенерирует, справочник по инструкциям твоего процессора (например 2й том Intel developer manual) и гугл. Просто бери, читай и разбирайся зачем так.

Я например думаю, что в будущем это профессия будет востребована в больших компаниях

Я тебе с уверенностью скажу, что эта профессия уже сейчас востребованна в больших компаниях соответствующего профиля.

Как практиковаться

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

error -110 whilst initialising SD card
В чем может быть проблема?

110 -- ETIMEDOUT. Там ещё дофига всего происходит "после успешного считывания регистров OCR и CID", нужно точнее определить место откуда приходит ошибка.

Смотря что имеется в виду под "переместить". До начала выполнения стек можно поместить в любое место. Потому что адресация в стеке всегда выполняется относительно указателя стека/указателя кадра. Во время работы указатель стека можно сдвигать вниз на произвольную глубину. Использованную часть стека перенести во время работы нельзя. Данные в общем случае перенести нельзя. Чтобы было можно, нужно использовать базовый регистр и обращаться по смещениям от него. Например, так работают TLS и FDPIC. С другой стороны, код сгенерированный как PIC/PIE можно перемещать вместе с данными, а если анализировать фиксапы и применять только те из них, которые ссылаются в сегмент данных, данные можно перемещать отдельно от кода.

Однако переключения контекста при вытесняющем планировании, а также порождённые ими инвалидации кэша никуда не денутся.

Но VIPT/PIPT кэш не нужно инвалидировать при переключении контекста, а VIVT, мне кажется, уже давно никто не делает.

make_request_fn определён как

typedef blk_qc_t (make_request_fn) (struct request_queue *q, struct bio *bio);

соответственно ваша функция filter_mrqfn должна возвращать blk_qc_t.

Кто может продолжить цепочку: реальное устройство eth0 инициирует прерывание -> процессор смотрит в таблице прерываний откуда брать код драйвера, а что дальше

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

Очень грубо: если сетевой пакет получен с одного из интерфейсов-слейвов бриджа -- посмотреть, есть ли для его адреса назначения запись в forwarding database, если есть -- переслать пакет в интерфейс из этой записи, если нет -- переслать во все интерфейсы этого бриджа, кроме того, через который пакет был получен.

Если хочется подробностей, можно почитать тут: it-ebooks.info/book/2195
Или тут: https://git.kernel.org/cgit/linux/kernel/git/torva... , там всего пара интересных файлов, по 500 строчек каждый.

https://wiki.archlinux.org/index.php/Audit_framewo...

Я вижу два странных момента.
Один у вас: доступ к 32-битным регистрам APIC не может выполняться как к 64-битной памяти. Об этом говорит intel developer's manual vol3, p 10.4.1:

All 32-bit registers should be accessed using 128-bit aligned 32-bit loads or stores.

Второй — в qemu. Там (смотрел текущую голову git) нет кода, который бы перемещал регистры при изменении базового адреса APIC.
На чём вы тестируете своё ядро?