Nafanya Смотрите структуру описывающие процесс, поток и там подобное .. И конечно функты сваминга контекстов. Аттачей модулей ядра к процессом(Адрессное пространство).
shchetinin Еще стек ядра забыли. Про LDT не сказали явно, но я полагаю, что Вы это к управляющим регистрам отнесли. Можно сказать короче: switch_mm() - переключает виртуальную память switch_to() - восстанавливает стек ядра и регистры процессора. Хорошо, что вы не стали все регистры перечислять, а только категории назвали
Ребята, а кто-нибудь из WASM'овцев принимал участие в Open Source разработке Linux Kernel? Я мельком глянул сейчас в LKML - там очень известные разрабы, некоторым по 40 лет, но есть и начинающие, вся переписка на Инглише. Хочу ещё на их комиты посмотреть - есть чему поучиться от людей с таким высоким уровнем. Кто-нибудь клонировал себе на тачку репозиторий ядра?
До утра ядерный репозиторий клонировал - он оказался очень мощным. Теперь можно практически в реальном времени (например раз в 3 часа) пулить коммиты и по ним отслеживать в какой участок кода ядра разработчики внесли изменения за это время и с чем эти изменения связаны. Я восхищен - каждый коммит сопровождается очень подробным комментарием. Всё на высоте. Взгляните какая красота:
Я тоже подсел на линух... Сейчас накопилось наработок по линух, что действительно очень удобно и гибко. Суперовская штука линух, хотя от винды пока полностью не отвязаться. Что только стоит одна эта срока: sudo apt-get install <любое нужное приложение> и через пару минут у вас есть все, что вы просили.
neutronion А Вы свои наработки на Review в сообщество отправьте. Отсылается по мылу diff - файл, отражающий изменения которые вы предлагаете внести в код ядра, также в письме должно присутствовать техническое обоснование необходимости этих изменений. Если код ревизию пройдёт (пусть даже не с первого раза - это нормально) и Ваши изменения включат в репозиторий, то Ваше имя начнёт фигурировать в системе контроля версий и все об Вас узнают. По-моему здорово систему придумали.
7mm Если хотя бы один Ваш коммит в репозиторий ядра включили, то это говорит о том, что у Вас очень высокий технический уровень. Позвольте узнать на какой подсистеме ядра Вы специализируетесь? Думаю, что в мире нет человека, знающего код всех подсистем ядра. Какую систему навигации по коду гигабайтного репозитория Вы используете? Студия умирает сразу от такого объёма(если только по частям код ядра разбивать(метров по 20) - то навигация работает за разумное время). Я пока не работал с репозиториями большими, чем 2 MB. Главная проблема, которую я пока не могу решить: навигация по репозиториям большого объёма. Конкретный пример. Представьте, что мы с Вами внутри планировщика и изучаем его код: A difinition for the symbol 'per_cpu' could not be located. ЧЁРТ, эта засада происходит всегда при навигации по ядру - как так можно изучать код! Видимо разрабы ядра применяют какие-то особые мне неведомые методики навигации по коду больших проектов.
В разное время приходилось работать с разными подсистемами - arch (x86, powerpc, arm), vfs, mm, net, security. Не могу сказать, что специализируюсь на чём-то одном. Обычно, задача определяет средства. При работе с кодом я в основном использую mc + grep + git log/show/blame и пр., мне этого хватает т.к. я достаточно хорошо уже знаю что где смотреть. Из индексаторов не могу посоветовать что-то конкретное, потому что как обычно в мире линукса есть варианты. Я для работы использую Emacs, поэтому если что, мой выбор - это ETAGS. Можете посмотреть на cscope или ctags. Но ещё раз повторюсь, я не использую локальные индексаторы для изучения кода - кстати, для этого есть хороший ресурс: http://lxr.linux.no/+trees
Это просто отлично. Не могли бы подсказать по планировщику: в sched.c лежит макрос: метод планировщика из sched.c: Чудес не бывает и макрос должен подставиться на стадии препроцессирования. Вопрос - откуда в данной единице трансляции возьмётся runqueues? Где объявление/определение этой переменной?
Нашёл, я в шоке. Вот так ядерщики объявляют экземпляр структуры rq: Код (Text): #define DEFINE_PER_CPU_SECTION(type, name, sec) \ __PCPU_ATTRS(sec) PER_CPU_DEF_ATTRIBUTES \ __typeof__(type) name #define DEFINE_PER_CPU_SHARED_ALIGNED(type, name) \ DEFINE_PER_CPU_SECTION(type, name, PER_CPU_SHARED_ALIGNED_SECTION) \ ____cacheline_aligned_in_smp static DEFINE_PER_CPU_SHARED_ALIGNED(struct rq, runqueues); И как система навигации должна догадаться, что static DEFINE_PER_CPU_SHARED_ALIGNED(struct rq, runqueues) - это на самом деле объявление переменной runqueues типа struct rq - у неё ведь нет искусственного интеллекта и она не знает, что обозначает __typeof__(type)? Ох уж эти extension'ы, как же этот код читать...
