Опыт разработки на уровне ядра Linux. Что это?

Писать модули ядра м.б.

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

Тогда отличается ли разработка принципиально новой файловой системы от написания дров в этом смысле?

Да.

Мне кажется, последнее обязательно, первое — желательно и будет большим плюсом при устройстве.

Вероятно, имеется в виду kernel-space programming.

Работодатель хочет, чтобы ты мог скомпилять ядро со своими изменения и после падения уметь посмотреть, почему оно не заработало.

Скорее всего умение общаться с девайсами через различные интерфейсы (/dev/*ctl, /sys, /proc)

Это значит, что у работодателя есть какие-то самопальные железяки, которые сидят на PCI/PCIx и для их работы надо писать модули ведра.

А вообще, не понимаю, зачем про это писать: свой модуль ведра любой может написать, тупо посидев недельку в гуголе! Это совершенно элементарная вещь, которую "даже лалка анскильная осилит" (c, Цар)

читая между строк: нужен опыт, но не навыки. Это значит всё что угодно. Настораживает несколько.

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

Поэтому нелишне будет составить списочек контрольных вопросов, типа:

- что такое джит и как вы его используете...

- какие лицензии в ходу

- как например будет реализовываться процедура публикации наработок с точки зрения прав, лицензий, авторства

- охват версий

после падения уметь посмотреть, почему оно не заработало.

А как это можно сделать? Если например паника при загрузке? Я просто задумывался над этим, но ничего не изучал серьезно.

А вообще, не понимаю, зачем про это писать: свой модуль ведра любой может написать, тупо посидев недельку в гуголе!

Неделя гугления, это уже, черт возьми, знания. :)

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

Скорей, не культуры, а терпения. Потому как терпеть издевания Линуса, который в каждой новой версии ломает совместимость со старыми — это особое качество! Скажем, написал ты мегакрутой модуль для ведра 2.2. А тут — фигакс, вышло 2.4. И ты тратишь месяц-другой на портирование. Потом — фигакс, выходит 2.6. Та же песня. А когда выходит 3.2, ты материшься очень сильно: тут уже полгода говно разгребать придется...

LTS-версии для решения таких проблем вроде как. До сих пор 2.6.32 на офииальном сайте. Другой вопрос, что ни один дистр уже наверное не поддерживает такие ядра. Проблема скорее всего в версиях gcc glibc...

Не думаю, что Линус тут сломал все - он как раз едва сдерживает себя мягко выражаясь, когда кто-то ломает что-то.

Ядро стало большое - распухло, git уже не спасает. Это плата за универсльность, с другой стороны это супер, когда одно ядро для разного железа.

Так то не надо тянуть на Линуса. Всегда есть выбор знать что это работать будет или нет.

это значит, что работодатель сам не знает, что он хочет. скорее всего, чтобы кандидат не впал в ступор, если понадобится пропатчить, пересобрать и задиплоить ядро. Беги от такого работодателя, мой тебе совет, как черт от ладана, ибо там ад из кривых самописных костылей.

Debian 6 до 2016 поддерживаться будет. Во всяком случае когда-то (после выхода Wheezy) об этом пробегала новость.

Не думаю, что Линус тут сломал все - он как раз едва сдерживает себя мягко выражаясь, когда кто-то ломает что-то.

stable_api_nonsense.txt

это значит, что ты должен ориентироваться в 9 секции мана не хуже чем во 2 и 3.

Что именно отпугнуло?

Что именно отпугнуло?

Написал один драйвер. Изделие работает примерно две недели и через две недели виснет на мертво. Зависание носит случайный характер. Воспроизводимость проблемы раз в две недели, это полный писец. Как отладить?

Найти баг не смог. Проблему решил повторным написанием с нуля этого драйвера. При этом, написание КАЖДОЙ строчки сопровождалось очень длительной медитацией и размышлением над всеми мыслимыми и немыслимыми ситуациями «Что может тут произойти, а что не может».

При этом, написание КАЖДОЙ строчки сопровождалось очень длительной медитацией и размышлением над всеми мыслимыми и немыслимыми ситуациями «Что может тут произойти, а что не может».

так это нормально когда пишешь многопоточный код и/или под многопоточную среду

так это нормально когда пишешь многопоточный код и/или под многопоточную среду

Я думаю что ты прав. В своем деле я все время стараюсь убежать от махровой многопоточности.