Второе издание
 Скачать 3.09 Mb.
|
|
Таблица 18.2. Список поддерживаемых команд SysRq Команда Описание SysRq-b SysRq-e SysRq-h SysRq-i SysRq-k i SysRq-l SysRq-m SysRq-o SysRq-p SysRq-r SysRq-s SysRq-t SysRq-u В файле D o c u m e n t a t i o n / s y s r q . t x t , который находится в каталоге исходных кодов ядра, приводится более полное описание. Реализация поддержки магической комбинации клавиш находится в файле d r i v e r s / c h a r / s y s r q . с . Магические ком- бинации клавиш SysRq — жизненно необходимый инструмент, который помогает в отладке и сохранении "гибнущей" системы, так как предоставляет большие возмож- ности для любого пользователя при работе с консолью. Тем не менее необходимо соблюдать осторожность при его использовании на критичных машинах. Если же машина используется для разработок, то польза от этих команд огромная. Отладка 383 Перегрузить машину (reboot) Послать сигнал S I G T E R M всем процессам, кроме процесса i n i t Отобразить на консоли помощь по использованию комбинаций клавиш SysRq Послать сигнал SIGKILL всем процессам, кроме процесса i n i t Клавиша безопасного доступа: завершить все процессы, связанные с текущей консолью Послать сигнал S I G K I L L всем процессам, включая процесс i n i t Отобразить на консоли дамп информации по использованию памяти Завершить работу машины (shutdown) Отобразить на консоли дамп регистров памяти Отключить прямой режим работы клавиатуры (raw mode) Синхронизировать данные смонтированных файловых систем с дисковыми устройствами Отобразить на консоли дамп информации о заданиях Размонтировать все смонтированные файловые системы Сага об отладчике ядра Многие разработчики ядра давно высказываются о необходимости встроенного в ядро отладчика. К сожалению, Линус не желает видеть отладчик ядра в своем де- реве исходного кода, Он уверен, что использование программ-отладчиков приводит к плохому исправлению ошибок неправильно информированными разработчиками. Никто не может поспорить с его логикой — исправления ошибок, построенные на основании хорошего понимания кода скорее всего будут верными. Тем не менее большинство разработчиков ядра все же нуждаются в официальном отладчике, встроенном в ядро. Поскольку такая возможность навряд ли появится в ближайшее время, то взамен было разработано несколько заплат, которые добавляют поддержку отладчика в стандартном ядре. Не смотря на то, что это внешние и неофициальные заплаты, они являются мощными инструментами с высокой функциональностью. Перед тем, как обращаться к этим решениям, посмотрим, на сколько нам может по- мочь стандартный отладчик ОС Linux - gdb. Использование отладчика gdb Для того, чтобы мельком заглянуть внутрь работающего ядра можно использо- вать стандартный отладчик GNU. Запуск отладчика для работы с ядром почти ни чем не отличается от отладки выполняющегося процесса. gdb vmlinux /proc/kcore Файл vmlinux — это декомпрессированный исполняемый образ ядра, который хранится в корне каталога исходных кодов, где выполнялась сборка выполняющего- ся ядра. Сжатые файлы zlmage, или bzlmage использовать нельзя. Опциональный параметр /proc/kcore исполняет роль файла core, чтобы позво- лить отладчику читать из памяти выполняющегося ядра. Чтобы иметь возможность читать этот файл, необходимо иметь права пользователя root. Можно пользоваться практически всеми командами программы gdb для чтения информации. Например, чтобы напечатать значение переменной можно восполбзо - ваться командой. р global_variable Для того, чтобы дизассемблировать код функции можно выполнить следующую команду. disassemble function Если ядро было скомпилировано с указанием флага -g (необходимо добавить -g к значению переменной CFLAGS в файле Makefile ядра), то отладчик gdb сможет выдавать больше информации. Например, можно выводить дампы структур данных и разыменовывать указатели. При этом также получается ядро значительно больше- го размера, поэтому для обычной работы не следует компилировать ядро с отладоч- ной информацией. К сожалению, на этом заканчиваются возможности использования отладчика gdb. С его помощью никак нельзя изменять данные ядра. Нет возможности пошагово вы- полнять код ядра, или устанавливать точки остановки (breakpoint). Невозможность изменять структуры данных ядра — это большой недостаток. Хотя очень полезно 384 Глава 18 иметь возможность дизассемблировать код функций, еще более полезной была бы возможность изменять структуры данных. Отладчик kgdb Отладчик kgdb —это заплата ядра, которая позволяет с помощью отладчика gdb отлаживать ядро по линии последовательной передачи. Для этого требуется два ком- пьютера. На перпом выполняется ядро с заплатой kgdb. Второй компьютер использу- ется для отладки ядра по линии последовательной передачи (нуль-модемный кабель, соединяющий две машины) с помощью gdb. Благодаря отладчику kgdb полностью доступен весь набор функций gdb: чтение и запись любых переменных, установка точек остановки, установка точек слежения (watch points), пошаговое исполнение и др.. Специальные версии kgdb даже позволяют вызывать функции. Установка kgdb и линии последовательной передачи несколько сложная проце- дура, но если ее выполнить, то отладка ядра значительно упрощается. Заплата ядра также устанавливает большое количество документации в каталог Documentation/, ее следует прочитать. Несколько человек выполняют поддержку заплаты kgdb для различных аппарат- ных платформ и версий ядра. Поиск в Интернет — наилучший способ найти необхо- димую заплату для заданного ядра. Отладчик kdb Альтернативой kgdb является отладчик kdb. В отличие от kgdb отладчик kdb — не удаленный отладчик. Отладчик kdb — это заплата, которая сильно модифициру- ет ядро и позволяет выполнять отладку прямо на той же машине, где выполняется ядро. Кроме всего прочего поддерживается возможность изменения переменных, установки точек остановки и пошаговое выполнение. Выполнять отладку просто — необходимо нажать на консоли клавишу b r e a k . При выводе сообщения oops пере- ход в отладчик выполняется автоматически. Более подробная документация доступ- на в каталоге Documentation/kdb после применения заплаты. Заплата kdb доступна в Интернет по адресу h t t p : / / o s s . s g i . c o m / . Исследование и тестирование системы По мере того, как вы будете накапливать опыт в отладке ядра, у вас будет по- являться все больше маленьких хитростей, которые помогают в исследовании и те- стировании ядра для получения ответов на интересующие вопросы. Так как отладка ядра требует больших усилий, то каждый маленький совет, или хитрость может ока- заться полезным. Рассмотрим несколько таких хитростей. Использование идентификатора UID в качестве условия Если разрабатываемый код связан с контекстом процесса, то иногда появляется возможность выполнить альтернативную реализацию не "ломая" существующий код. Это важно, если необходимо переписать важный системный вызов и при этом не- обходима полностью функционирующая система, на которой этот вызов нужно отла- дить. Например, допустим, что нужно переписать алгоритм работы системного вы- Отладка 385 зова f o r k ( ) , который бы использовал некоторые новые возможности, которые уже существуют в ядре. Если сразу не получится все сделать так как надо, то будет очень тяжело отлаживать ядро, так как неработающий системный вызов f o r k () скорее всего приведет к неработоспособности системы. Но как и всегда, есть надежда. Часто безопасным будет сохранить старый алгоритм, а новую реализацию выпол- нить в другом месте. Этого можно достичь используя идентификатор пользователя (UID) в качестве условия того, какой алгоритм использовать. if (current->uid != 7777) { /* старый алгоритм .. */ } else { /* новый алгоритм .. */ } lice пользователи, кроме того, у которого идентификатор UID равен 7777 будут использовать старый алгоритм. Для тестирования нового алгоритма можно создать нового пользователя с идентификатором 7777. Это позволяет более просто оттести- ровать критические участки кода, связанные с выполнением процессов. Использование условных переменных Если код, который необходимо протестировать, выполняется не в контексте процесса, или необходим более глобальный метод для контроля новых функций, то можно использовать условные переменные. Этот подход даже более простой, чем использование идентификатора пользователя. Необходимо просто создать глобаль- ную переменную и использовать ее в качестве условия выполнения того, или дру- гого участка кода. Если значение переменной равно нулю, то следует выполнить один участок кода. Если переменная не равна нулю, то выполняется другой участок. Значение переменной может быть установлено с помощью отладчика, или специаль- ного экспортируемого интерфейса. Использование статистики Иногда необходимо получить представление о том, насколько часто происходит некоторое событие. Иногда требуется сравнить несколько событий и вычислить ха- рактеристики для их сравнения. Это очень легко сделать путем введения статистки и механизма для экспортирования соответствующих параметров. Например, допустим, что необходимо выяснить на сколько часто происходит со- бытие foo и событие bar. В файле исходного кода, в идеале там, где соответствующие события возникают, вводится две глобальные переменные. unsigned long foo_stat = 0; unsigned long bar_stat = 0; Как только наступает интересующее событие, значение соответствующей пере- менной увеличивается на единицу. Эти переменные могут быть экспортированы как угодно. Например, можно создать интерфейс к ним через файловую систему /ргос, или написать свой системный вызов. Наиболее просто прочитать их значение с по- мощью отладчика. Следует обратить внимание, что такой подход принципиально не безопасен на SMP машине. В идеале необходимо использовать атомарные переменные. Однако, 386 Глава 18 для временной статистики, которая необходима только для отладки, никакой защи- ты обычно не требуется. Ограничение частоты следования событий при отладке Часто необходимо встроить в код отладочные проверки (с соответствующими функциями вывода информации), чтобы визуально производить мониторинг пробле- мы. Однако, в ядре некоторые функции вызываются по много раз в секунду. Если в такую функцию будет встроен вызов функции printk (), то системная консоль будет перегружена выводом отладочных сообщений и ее будет невозможно использовать. Для предотвращения такой проблемы существует два сравнительно простых при- ема. Первый — ограничение частоты следования событий — очень полезен, когда не- обходимо наблюдать, как развивается событие, но частота возникновения события очень большая. Чтобы ограничить поток отладочных сообщений, эти сообщения вы- водятся только раз в несколько секунд, как это показано в следующем примере. static unsigned long prev_jiffy = jiffies; /* ограничение частоты */ if (time_after (jiffies, prev_jiffy + 2*HZ)) { prev_jiffy = jiffies; printk (KERN_ERR "blah blah blah\n"); } В этом примере отладочные сообщения выводятся не чаще, чем один раз в две секунды. Это предотвращает перегрузку консоли сообщениями и системой можно нормально пользоваться. Частота вывода может быть большей, или меньшей, в за- висимости от требопаний. Вторая ситуация имеет место, когда необходимо замечать любые появления со- бытия. В отличие от предыдущего примера нет необходимости выполнять мони- торинг развития событий. А только получить сообщение о том, что что-то произо- шло. Вероятно это уведомление необходимо получить один, или два раза. Проблема возникает в том случае, если проверка, которая после того, как сработала один раз, начинает срабатывать постоянно. Решением в данном случае будет не ограничение частоты, а ограничение общего количества повторений. static unsigned long limit = 0; if (limit < 5) { limit++; printk(KERN_ERR "blah blah blah\n"); } . , В этом примере количество отладочных сообщений ограничено числом пять. После пяти сообщений условие всегда будет ложно. В обоих примерах переменные должны быть статическими ( s t a t i c ) и локаль- ными по отношению к той функции, где используются. Это позволяет использовать одинаковые имена переменных в разных функциях. Ни один из этих примеров не рассчитан на SMP, или преемптивность, хотя очень легко перейти к атомарным операциям и сделать их безопасными для использова- ния и в этих случаях. Однако, честно говоря, это всего лишь отладочный код, поэто- му зачем нужны лишние проблемы? Отладка 387 Нахождение исполняемых образов с изменениями приводящими к ошибкам Обычно полезно знать, в какой версии исходных кодов ядра появился дефект. Если известно, что дефект появился в версии 2.4.18, но его не было в версии 2.4.17, то сразу появляется ясная картина изменений, которые привели к появлению ошиб- ки. Исправление ошибки сводится к обратным изменениям, или другим исправлени- ям измененного кода. Однако, чаще оказывается неизвестным в какой версии появился дефект. Известно, что проблема проявляется в текущей версии ядра, и кажется, что она всег- да была в текущей версии. Хотя это и требует некоторой исследовательской работы, но приложив небольшие усилия можно найти изменения, которые привели к ошиб- кам. Если известны эти изменения, то до исправления ошибки уже недалеко. Для того, чтобы начать, необходима четко повторяемая проблема. Желательно, чтобы проблема проявлялась сразу же после загрузки системы. Далее необходимо гарантированно работающее ядро. Вероятно, это ядро уже известно. Например, может оказаться, что пару месяцев назад ядро работало нормально, поэтому стоит взять ядро того времени. Если это не помогает, то можно воспользоваться еще бо- лее старой версией. Такой поиск ядра без дефекта должен быть не сложным, если, конечно, дефект не существовал всегда. Далее, необходимо ядро, в котором гарантированно есть дефект. Для облегче- ния поиска следует воспользоваться наиболее ранней версией ядра, в которой есть дефект. После этого начинается поиск исполняемого образа, в котором появилась ошибка. Рассмотрим пример. Допустим, что последнее ядро, в котором не было ошибки— 2.4.11, а последнее с ошибкой— 2.4.20. Начинаем с версии ядра, которая находится посредине— 2.4.15. Проверяем версию 2.4.15 на наличие ошибки. Если версия 2.4.15 работает, значит ошибка появилась в более поздней версии. Следует попробовать версию между 2.4.15 и 2.4.20, скажем версию 2.4.17. С другой стороны, если версия 2.4.15 не работает, то тогда ясно, что ошибка появилась в более ранней версии, и следует попробовать версию, скажем 2-4.13. И так далее. В конце концов проблема сужается до двух ядер — одно с дефектом, а другое — без. В таком случае есть ясная картина изменений, которые привели к проблеме. Такой подход избавляет от необходимости проверять ядра всех версий! Если ничто не помогает — обратитесь к сообществу Возможно, вы уже испробовали все, что знали. Вы просидели за клавиатурой не- счетное количество часов, и даже дней, а решение все еще не найдено. Если про- блема в основном ядре Linux, то всегда можно обратиться за помощью к людям из сообщества разработчиков ядра. Короткое, но достаточно детальное описание проблемы вместе с вашими наход- ками, посланное в список рассылки разработчиков ядра по электронной почте, мо- жет помочь отыскать решение. В конце концов, дефектов никто не любит. Глава 20, "Заплаты, разработка и сообщество" специально посвящена сообществу разработчиков ядра и его основному форуму — списку рассылки разработчиков ядра Linux (Linux Kernel Mail List, LKML). 388 Глава 18 19 Переносимость L inux — переносимая операционная система, которая поддерживает большое ко- личество различных компьютерных аппаратных платформ. Переносимость— это свойство, которое указывает, насколько легко можно перенести код, который вы- полнялся на одной аппаратной платформе, для выполнения на другой аппаратной платформе (если вообще это возможно). Известно, что ОС Linux является переноси- мой операционной системой, поскольку ее уже перенесли (портировали) па большое количество различных аппаратных платформ. Тем не менее переносимость не воз- никает сама по себе, для выполнения она требует большого количества проектных решений. Сегодня процесс перенесения ОС Linux на другую аппаратную платформу достаточно прост (в относительном смысле, конечно). В этой главе рассказывается о том, как писать переносимый код, — вопрос, о котором всегда необходимо помнить при написании нового кода ядра или драйверов устройств. Некоторые операционные системы специально разрабатываются с учетом требо- ваний переносимости как главного свойства. По возможности минимальное количе- ство кода выполняется зависимым от аппаратуры. Разработка на языке ассемблера сводится к минимуму, а интерфейсы и свойства выполняются принципиально общи- ми и абстрактными, чтобы иметь возможность работать на различных аппаратных платформах. Очевидным преимуществом в этом случае является легкость поддерж- ки новой аппаратной платформы. В некоторых случаях простые операционные си- стемы с высокой переносимостью могут быть нормированы на новую аппаратную платформу только путем изменения нескольких сотен строк специфичного кода. Недостаток такого подхода состоит в том, что не используются специфические свойства аппаратной платформы и код не может быть в ручную оптимизирован под конкретную машину. Переносимость ставится выше оптимальности. Примером опе- рационных систем с высокой переносимостью могут быть Minix, OpenBSD и многие исследовательские системы. С противоположной стороны можно поставить операционные системы, в кото- рых оптимизация кода выполняется в ущерб переносимости. Код, по возможности, пишется на языке ассемблера или специфические свойства аппаратных платформ ис- пользуются каким-либо другим образом. Свойства ядра разрабатываются на основа- нии свойств аппаратной платформы. В этом случае перенос операционной системы на другую аппаратную платформу сводится к написанию ядра с нуля. Оптимальность выполняется в ущерб переносимости. Примером таких систем могут быть DOS и Windows 9x. Сегодня таким системам нет необходимости иметь более оптимальный код, чем переносимым операционным системам, однако они предоставляют возмож- ность в максимальной степени использовать ручную оптимизацию кода. Операционная система Linux в плане переносимости занимает промежуточное положение. Насколько это целесообразно из практических соображений, интерфей- сы и код сохраняются независимыми от аппаратной платформы и пишутся на язы- ке С. Однако функции ядра, которые критичны к производительности, выполняются зависимыми от аппаратной платформы. Например, низкоуровневый код и код, кото- рый должен выполняться очень быстро, разрабатывается зависимым от аппаратной платформы и обычно на языке ассемблера. Такой подход позволяет сохранить пере- носимость ОС Linux и при этом воспользоваться оптимизациями. В случаях, когда переносимость становится помехой производительности, произ- водительность обычно всегда побеждает. В остальных случая сохраняется переноси- мость кода. Обычно экспортируемые интерфейсы ядра независимы от аппаратной платфор- мы. Если различные части одной подпрограммы должны быть разными для разных аппаратных платформ (из соображений производительности или по необходимо- сти), то код выполняется в виде нескольких функций, которые вызываются, в нуж- ных местах. Для каждой поддерживаемой аппаратной платформы реализуются свои функции, которые затем компонуются в общий исполняемый образ ядра. Хороший пример — планртровщик. Большая часть планировщика-написана незави- симым от аппаратной платформы образом на языке С. Реализация находится в фай- ле k e r n e l / s c h e d . с . Некоторые из функций планировщика, такие как переключе- ние состояния процессора или переключение адресного пространства, очень сильно зависят от аппаратной платформы. Следовательно, функция c o n t e x t _ s w i t c h (), ко- торая переключает выполнение от одного процесса к другому и написана на языке С, вызывает функции s w i t c h _ t o () и Kwitch_ram () для переключения состояния процессора и переключения адресного пространства соответственно. Код функций s w i t c h _ t o () и s w i t c h _ m m () выполнен отдельно для каждой ап- паратной платформы, которую поддерживает операционная система Linux. Когда операционная система Linux портируется на новую аппаратную платформу, то для новой аппаратной платформы просто необходимо реализовать эти функции. Файлы, которые относятся к определенной аппаратной платформе, находятся в каталоге arch/<аппаратная платформа>/ и include/asm- где <апппаратная платформа> — это короткое имя, которое представляет аппарат- ную платформу, поддерживаемую ядром Linux. Например, аппаратной платформе Intel х8б присвоено имя i386. Для этого типа машин файлы находятся в каталогах a r c h / i 3 8 6 и i n c l u d e / a s m - i 3 8 6 . Ядра серии 2.6 поддерживают следующие аппа- ратные платформы: a l p h a , arm, c r i s , h8300, i38, i a 6 4 , m68k, m68knommu, mips, mips64, p a r i s c , ppc, ppc64, s390, sh, s p a r e , sparc64, um, v850 и х8б-б4. Более полное описание приведено в табл. 19.1. История переносимости Linux Когда Линус Торвальдс впервые выпустил операционную систему Linux в ничего не подозревающий мир, эта ОС работала только на аппаратной платформе Intel i386. Хотя данная операционная система и была достаточно хорошо обобщена и хорошо написана, переносимость для нее не была основным требованием. Однажды Линус даже говорил, что операционная система Linux не будет работать ни на какой ап- паратной платформе, кроме i386! Тем не менее в 1993 году началась работа по пор- 390 Глава 19 тиропаиию ОС Linux на машины Digital Alpha. Аппаратная платформа Digital Alpha была повой высокопроизводительной RISC-платформой с поддержкой 64-разрядной адресации памяти. Она очень сильно отличалась от аппаратной платформы i386, о которой говорил Линус. Тем не менее, первоначальный перенос на аппаратную плат- форму Alpha занял около года, и аппаратная платформа Alpha стала первой офици- ально поддерживаемой аппаратной платформой после х8б. Это портировапие было, наверное, самым сложным, потому что — первым. Вместо простого переписывания ядра для поддержки новой аппаратной платформы, части ядра были переписаны с целью введения переносимости 1 . Хотя это и привело к выполнению большого коли- чества работы, в результате получился более ясный для понимания код, и в будущем перенос стало выполнять более просто. Первые выпуски ОС Linux поддерживали только платформу i386, а серия ядер 1.2 уже поддерживала Digital Alpha, Intel x86, MIPS и SPARC, хотя такая поддержка была отчасти экспериментальной. С выпуском ядра версии 2.0 была добавлена официальная поддержка платформ Motorola 68k и PowerPC. В дополнение к этому поддержка всех аппаратных плат- форм, которые ранее поддерживались ядрами серии 1.2, стала официальной и ста- бильной. В серию ядер 2.2 была введена поддержка еще большего количества аппаратных платформ: добавлены ARM, IBM S/390 и UltraSPARC. Через несколько лет в серии ядер 2.4 количество поддерживаемых аппаратных платформ было почти удвоено, и их количество стало равным 15. Была добавлена поддержка платформ CRIS, IA-64, 64-разрядная MIPS, HP PA-RISC, 64-разрядная IBM S/390 и Hitachi SH. В серии 2.6 количество поддерживаемых аппаратных платформ было доведено до 20 за счет добавления платформ Motorola 68k бел устройства MMU, Н8/300, IBM POWER, v850, x86-64 и версии ядра, которое работает на виртуальной машине под ОС Linux - Usermode Linux. Поддержка 64-разрядной s390 была объединена с 32- разрядной платформой s390, чтобы избежать дублирования. Необходимо заметить, что каждая из этих аппаратных платформ поддерживает различные типы машин и микросхем. Некоторые из поддерживаемых аппаратных платформ, такие как ARM и PowerPC, поддерживают очень большое количество ти- пов микросхем и машин. Поэтому, хотя ОС Linux и работает на 20 аппаратных плат- формах, она работает на гораздо большем количестве типов компьютеров! Размер машинного слова и типы данных Машинное слово (word) — это количество данных, которые процессор может обработать за одну операцию. Здесь можно применить аналогию документа, состо- ящего из символов (character, 8 бит) и страниц (много слов). Слово— это некоторое количество битов, как правило 16, 32 или 64. Когда говорят о "n-битовой" машине, то чаще всего имеют в виду размер машинного слова. Например, когда говорят, что процессор Intel Pentium — это 32-разрядный процессор, то обычно имеют в виду раз- мер машинного слова, равный 32 бит, или 4 байт. 1 Это нормальная ситуация при разработке ядра. Если что-либо должно быть сделано, то это долж- но быть сделано хорошо! Разработчики ядра неохотно переписывают большие участки кода даже во имя совершенства. Переносимость 391 Размер процессорных регистров общего назначения равен размеру машинного слова этого процессора. Обычно разрядность остальных компонентов этой же аппа- ратной платформы в точности равна размеру машинного слова. Кроме того, по край- ней мере для аппаратных платформ, которые поддерживаются ОС Linux, размер адресного пространства соответствует размеру машинного слова 2 . Следовательно, размер указателя равен размеру машинного слова. В дополнение к этому, размер типа long языка С также равен размеру машинного слова. Например, для аппарат- ной платформы Alpha размер машинного слова равен 64 бит. Следовательно, реги- стры, указатели и тип long имеют размер 64 бит. Тип i n t для этой платформы име- ет размер 32 бит. Машины платформы Alpha могут обработать 64 бит— одно слово с помощью одной операции. |