LXF73:Вскрываем ядро - История изменений

Yaleks: викификация

2009-01-17T17:32:37Z

викификация

Внесённые изменения

Yaleks: /* Взгляд в будущее */

2009-01-17T17:30:37Z

‎Взгляд в будущее

Yaleks: /* Поиски стабильности */

2009-01-17T17:14:36Z

‎Поиски стабильности

Внесённые изменения

Yaleks: /* «Продвинутые» особенности ядра */

2009-01-17T16:47:57Z

‎«Продвинутые» особенности ядра

Внесённые изменения

Yaleks: Новая: == Вскрываем ЯДРО == ''Знаток ядра '''Грег Кроа-Хартман''' (Greg Kroah-Hartman) заглянул внутрь последнего ядра, что...

2009-01-17T09:33:26Z

Новая: == Вскрываем ЯДРО == ''Знаток ядра '''Грег Кроа-Хартман''' (Greg Kroah-Hartman) заглянул внутрь последнего ядра, что...

Новая страница

== Вскрываем ЯДРО ==
''Знаток ядра '''Грег Кроа-Хартман''' (Greg Kroah-Hartman) заглянул внутрь последнего ядра, чтобы показать вам, что заставит ваш ПК работать на полную мощность.''

«С технической точки зрения, я верю, что ядро будет
сохранять те же черты, а всё действительно интересное будут
происходить в пространстве пользователя»
Линус Торвальдс (Linux Torvalds), 2001 год.

Несмотря на то, о что думает
доброжелательный «хранитель
сообщества», ядро Linux
демонстрирует, что оно является очень интересной и важной частью
системы. На самом нижнем уровне, ядро
отвечает за нормальную работу аппаратного обеспечения (того, на что вы, обычно, тратите много денег). Это позволяет
вам запускать ваш любимый web-браузер,
клиент электронной почты, программу
IRC, трехмерную «стрелялку» и т.д., одновременно. Без него не было бы Linux.

С появлением ядер серии 2.6 в конце
2003 года, разработчики ядра предоставили миру предельно стабильную, поддерживающую многопроцессорность
операционную систему, работающую
быстрее любой другой ОС на широком
спектре типов процессоров. Какая еще
операционная система может масштабироваться для использования что в крохотном MP3-плеере или встроенном в
робота контроллере, что в крупнейших
суперкомпьютерах (некоторые с более
чем 512 процессорами)? Все это возможно только благодаря самому ядру:
остальные компоненты, работающие на
более высоких уровнях – лишь надстройки над ним.

=== «Продвинутые» особенности ядра ===
''Каждому из нас следует уделить немного времени, чтобы лучше познакомиться с ядром. Последняя версия содержит ряд замечательных дополнений, которые будут полезны всем категориям пользователей.''

=== Начнем, пожалуй ===
''Вашим программистским пальцам не терпится начать? Углубимся в новое ядро и рассмотрим две самые замечательные функции.''

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

Ну что ж, начнем: если вы хотя бы в
общих чертах разбираетесь в языке C, вы
можете «сразиться» с Inotify, изучив новые функции ядра для добавления и удаления
точек слежения (watches) за файлами.

Если же вы не настолько бесстрашны,
читайте врезку «Привязка драйверов вручную», чтобы узнать, как можно настроить
драйвер, чтобы он автоматически подгружался при подключении устройств типа USB
Flash.

{{Врезка|center|
|Заголовок=Привязка драйверов вручную – использование функций bind и unbind
|Содержание=Приведем пример того, как использовать новые
функции bind и unbind ядра 2.6.13. Вам
потребуется flash-диск USB, или любое другое
устройство, управляемое драйвером usb-storage.
Прежде всего, пересоберите ядро (см. ссылку в
конце предыдущей страницы) с поддержкой
драйверов CONFIG_BLK_DEV_UB и CONFIG_USB_STORAGE (вы можете собрать их оба как
модули, а можете включить в основную часть
ядра).

Когда вы загрузите новое ядро, подключите
ваш flash-диск USB. Поскольку драйвер ub будет
найден первым в пути загрузки ядра, он будет
связан с вашим устройством. Это можно увидеть
в каталоге /sys/bus/usb/drivers/ub:
<source lang="bash">$ tree /sys/bus/usb/drivers/ub//sys/bus/usb/drivers/ub/
|-- 1-1:1.0 -> ../../../../devices/pci0000:00/
0000:00:1d.7/usb1/1-1/1-1:1.0
|-- bind
|-- module -> ../../../../module/ub
`-- unbind</source>
Обратите внимание, что в этом каталоге есть
файлы bind и unbind. Чтобы разорвать связь
устройства с драйвером, просто запишите
идентификатор шины (bus ID) устройства,
поддержку которого вы хотите деактивировать, в
файл unbind.
<source lang="bash">echo -n "1-1:1.0" > /sys/bus/usb/drivers/ub/unbind</source>
Устройство больше не связано с драйвером.
<source lang="bash">$ tree /sys/bus/usb/drivers/ub/
/sys/bus/usb/drivers/ub/
|-- bind
|-- module -> ../../../../module/ub
`-- unbind</source>
Чтобы связать это устройство с другим
драйвером, сначала убедитесь, что оно не
управляется чем-либо еще. Чтобы проверить это,
поищите символическую ссылку на драйвер в
каталоге устройства:
<source lang="bash">$ tree /sys/bus/usb/devices/1-1:1.0
/sys/bus/usb/devices/1-1:1.0
|-- bAlternateSetting
|-- bInterfaceClass
|-- bInterface Protocol
|-- bInterfaceSubClass
|-- bNumEndpoints
|-- bus -> ../../../../../../bus/usb
|-- modalias
`-- power
`-- state</source>
Затем просто запишите идентификатор шины
(bus ID) устройства, которое вы хотите связать, в
файл bind для нужного драйвера:
<source lang="bash">echo -n "1-1:1.0" > /sys/bus/usb/drivers/usbstorage/bind</source>
И проверьте, что привязка прошла успешно:
<source lang="bash">$ tree /sys/bus/usb/devices/1-1:1.0
/sys/bus/usb/devices/1-1:1.0
|-- bAlternateSetting
|-- bInterfaceClass
|-- bInterfaceNumber
|-- bInterfaceProtocol
|-- bInterfaceSubClass
|-- bNumberEndpoints
|-- bus -> ../../../../../../../bus/usb
|-- driver -> ../../../../../../bus/usb/drivers/usb-storage
|-- host2
| `-- power
| `-- state
|-- modalias
`-- power
`-- state</source>
Чтобы успешно связать некоторое устройство с
драйвером, последний должен распознавать
данное устройство. Поэтому вы не можете просто
произвольно связать любой драйвер с любым
устройством. Чтобы было проще добавлять
поддержку нового устройства в драйвер уже
после его сборки, система PCI предлагает файл
dynamic_id в sysfs, так что идентификатор нового
устройства, к которому следует привязать тот или
иной драйвер, можно задать из пространства
пользователя.
|Ширина=}}

==== Внутри Inotify ====
Функция Inotify добавляет три новых системных вызова:
<source lang="C">int inotify_init(void);
int inotify_add_watch(int fd, const char
*path, __u32 mask);
int inotify_rm_watch(int fd, __u32 mask);</source>
Выступая как замена для Dnotify, Inotify
работает с сущностями, называемыми точками слежения (watch). Watch – это пара
«объект-маска», которая описывает событие,
о наступлении которого пользователь хотел
бы получать уведомления. Объект – это
файл или каталог (представлен дескриптором открытого файла), а маска – битовое
описание событий. Р азличные типы событий, которые можно отслеживать, приведены ниже:
* IN_ACCESS: к файлу был доступ;
* IN_MODIFY: файл был изменен;
* IN_ATTRIB: были изменены метаданные файла;
* IN_CLOSE_WRITE: файл был закрыт с записью всех изменений;
* IN_CLOSE_NOWRITE: файл был закрыт без записи изменений;
* IN_OPEN: файл был открыт;
* IN_MOVED_FROM: файл был перемещен из положения X;
* IN_MOVED_TO: файл был перемещен в положение Y;
* IN_CREATE: файл в каталоге был создан;
* IN_DELETE: файл в каталоге был удален;
* IN_DELETE_SELF: объект наблюдения был удален.
Если пользователь хочет отслеживать
все события, определен удобный макрос
IN_ALL_EVENTS, который включает флаги
всех перечисленных выше событий.

Чтобы создать точку слежения и зарегистрировать ее в ядре, нужно получить
дескриптор с помощью вызова функции
inotify_init(), например, так:
<source lang="C">int fd = inotify_init();</source>
Затем, используя этот новый файловый
дескриптор, вы можете добавить watch к
нему, используя функцию
inotify_add_watch():
<source lang="C">int wd = inotify_add_watch(fd, path, mask);</source>
где fd – дескриптор, возвращенный
функцией inotify_init(); path – путь
к файлу или каталогу, за которым вы хотели бы наблюдать; и mask – тип события,
которое вы будете отслеживать.

Функция inotify_add_watch() возвращает указатель на дескриптор watch, который должен быть сохранен, чтобы правильно выполнить очистку.

Чтобы удалить точку слежения, которая
уже создана, используйте функцию
inotify_rm_watch():
<source lang="C">int retval = inotify_rm_watch(fd, wd);</source>
где fd – первоначальный файловый
дескриптор, возвращенный inotify_init(),
и wd – дескриптор watch, возвращенный
при вызове inotify_add_watch().

как только watch будет зарегистрирован
в ядре, получить события можно простым
вызовом read() для файлового дескриптора, соответствующего этой точке слежения
(и всем другим точкам слежения, которые
были зарегистрированы для данного
процесса).

Структура данных, которые могут быть
получены от ядра, описывается следующим
кодом на C:
<source lang="C">struct inotify_event {
__s32 wd; /* дескриптор точки слежения */
__u32 mask; /* маска */
__u32 cookie; /* cookie для синхронизации событий */
__u32 len; /* длинна имени (с завершающим нулем) */
char name[0]; /* место для размещения имени */
};</source>
{{Врезка
|Заголовок=за кадром
|Содержание=Чтобы узнать больше о решениях по
структуре ядра, через которые прошли
разработчики Inotify, создавая эту
систему, смотрите документацию по
Inotify в файле Documentation/filesystems/inotify.txt.
|Ширина=200px}}
Названия полей говорят сами за себя,
за исключением поля cookie. если это поле
имеет ненулевое значение, это значит, что
для данного объекта возникло несколько
событий одновременно. В качестве примера
можно привести переименование файла.
если мы будем наблюдать за каталогом,
в котором будет переименован файл
(mv foo baz), произойдут два события:
IN_MOVE_FROM и IN_MOVE_TO. Оба
они будут иметь одинаковое значение
cookie, что позволит пользовательской программе скоординировать эти события.

Файловый дескриптор, возвращаемый
inotify_init(), позволяет использовать
вызовы select() и poll(), так что блокирующий вызов read() не является
необходимым.

когда программа, удерживающая первоначальный файловый дескриптор, возвращенный inotify_init(), завершает работу (или если этот файловый дескриптор
будет закрыт), все точки слежения, которые
были зарегистрированы ядром, уничтожаются и очищаются соответствующим
образом.

В качестве очень простого примера
программы, который показывает, как
регистрировать события и читать их по
мере наступления, посмотрите пакет
inotify-utils, который можно найти на
странице http://www.kernel.org/pub/linux/kernel/people/rml/inotify/utils.

=== Поиски стабильности ===
''Лоскутные заплатки, «горячие» исправления, два дерева становятся одним… Как процесс разработки ядра изменился в лучшую сторону за последние пять лет.''

=== Взгляд в будущее ===
''Разработчики ядра проводят все более жесткую политику в отношении закрытого кода – но также хотелось бы, чтобы новая модель разработки не закрыла путь для инноваций.''

[[Категория:Специальный репортаж]]

← Предыдущая		Версия 17:30, 17 января 2009
Строка 694:		Строка 694:
	''Разработчики ядра проводят все более жесткую политику в отношении закрытого кода – но также хотелось бы, чтобы новая модель разработки не закрыла путь для инноваций.''		''Разработчики ядра проводят все более жесткую политику в отношении закрытого кода – но также хотелось бы, чтобы новая модель разработки не закрыла путь для инноваций.''

		+	Раньше разработчики ядра Linux искали обходной путь, когда создавались модули с недоступным для них исходным кодом. Но в последние годы все изменилось.
		+	Теперь существует три способа, которыми
		+	разработчики ядра разрешают такие
		+	ситуации.

		+	Первый – это флаг, который устанавливается всякий раз, когда загружается модуль с закрытым кодом. Это позволяет сообществу разработчиков легко опознать и
		+	отказаться от поддержки всех пользователей с такими модулями, поскольку в этом
		+	случае невозможно точно определить, где
		+	находится источник проблемы (в секции
		+	с закрытым кодом или в остальной части
		+	ядра).
		+
		+	Почти все новые функции ядра явно помечаются компилятором как доступные
		+	только из открытого GPL-кода. Этот подход
		+	запрещает любому модулю с закрытым кодом использовать их интерфейсы, и постепенно будет «душить» все их функциональные возможности. Хороший пример этого –
		+	базовые интерфейсы для драйверов и sysfs,
		+	которые недоступны для модулей с закрытым кодом.
		+
		+	==== буква закона ====
		+	Видимо, этого было недостаточно, чтобы
		+	переубедить заблудших программистов, и разработчиками ядра был подан судебный иск в отношении поставщиков Linux, создающих закрытые модули (поскольку повторное
		+	распространение закрытых модулей незаконно, как определено
		+	в лицензии GPL). Оказалось,
		+	что это весьма эффективно,
		+	поскольку никакие Linux-компании не хотели иметь дело с законом в этой связи.
		+
		+	Теперь перейдем к третьему средству
		+	сдерживания. Основные претензии по поводу процесса разработки ядра предъявлялись производителями драйверов, являвшимися внешними по отношению к дереву
		+	исходного кода ядра и содержащими проприетарные наработки – такими, например,
		+	как NVIDIA.
		+
		+	Эти претензии обычно были связаны
		+	с тем, что внутренние интерфейсы ядра постоянно меняются, в отличие от других операционных систем, которые имеют хорошо
		+	определенный и постоянный, встроенный в
		+	ядро, интерфейс, который можно
		+	использовать.
		+
		+	Программный же интерфейс ядра Linux
		+	меняется довольно часто по следующей
		+	причине: разработчики ядра обычно изменяют то, как ядро работает внутренне, устраняя ошибки и проблемы безопасности или
		+	дополняя его новыми возможностями.
		+
		+	Чтобы делать это эффективно, старые
		+	интерфейсы приходится удалять или изменять, одновременно исправляя все прочие
		+	компоненты, в которых эти интерфейсы использовались. Это позволяет ядру Linux оставаться настолько маленьким, насколько
		+	это возможно без потери работоспособности каких-либо драйверов, которые содержатся в дереве исходного кода ядра. Это
		+	также принуждает разработчиков помещать
		+	свой код в главное дерево ядра, что позволяет большему числу людей видеть код и
		+	работать с ним, получая преимущества от
		+	процесса создания открытого кода.
		+
		+	Чтобы узнать подробное описание причин, по которым Linux не может сохранять
		+	стабильный интерфейс ядра, прочитайте документ http://lxr.linux.no/source/Documentation/stable_api_nonsense.txt.
		+
		+	==== Появится ли когда-либо 2.7? ====
		+	В прошлом, когда разработчики ядра решили ограничиться одним деревом исходного
		+	кода, упоминался ряд серьезных изменений,
		+	которые могли бы поспособствовать ответвлению 2.7 от основного ядра. две из таких
		+	особенностей – это четырехуровневые таблицы страниц и переписанная подсистема
		+	времени ядра. Однако дерево 2.6 сейчас
		+	уже имеет четырехуровневые таблицы (позволяющие использовать терабайты виртуальной памяти), а также имеется переписанный код для подсистемы времени ядра,
		+	ожидающий включения в будущие версии.
		+
		+	Это привело к тому, что, не имея экспериментального дерева ядра, в котором можно было бы возиться со всем, с чем заблагорассудится, разработчики вынуждены
		+	действовать очень осторожно, что и происходит. Хотя и было сделано несколько серьезных модификаций, затрагивающих способы функционирования ядра, любые усовершенствования происходят как устойчивые,
		+	инкрементальные изменения.
		+
		+	В результате, в середине стабильного
		+	цикла происходили крупные изменения, а
		+	пользователи не заметили никаких побочных эффектов. Новая модель заставляет
		+	разработчиков ядра становиться лучшими
		+	инженерами, которые в состоянии поддерживать более быструю, более стабильную
		+	операционную систему.
		+
		+	{{Врезка\|center\|
		+	\|Заголовок=ПрисоединяЙтесь!
		+	\|Содержание=Вы хотите помочь в разработке ядра, но не знаете, с чего начать? если
		+	вы хорошо понимаете язык C и знаете, как собирать и устанавливать
		+	собственное ядро, попробуйте посмотреть проект Kernel Janitors на
		+	http://janitor.kernelnewbies.org. Он содержит список простых
		+	проектов для начинающих разработчиков, которые только осваивают
		+	работу с ядром. Список рассылки проекта поможет вам выяснить
		+	соответствующую процедуру и формат для создания изменений и
		+	отправки их на включение в ядро.
		+
		+	для разработчиков, которым нужен “легкий толчок” в правильном
		+	направлении, существует проект Kernel Mentor (http://selenic.com/mailman/listinfo/kernel-mentors). Он поможет разработчикам
		+	изучить соответствующие «правила движения», которые нужно
		+	соблюдать для «заливки» изменений в основное дерево кода ядра.
		+
		+	И если вы непременно желаете делать все самостоятельно, вам
		+	следует начать с чтения руководства по коду ядра Linux на http://lxr.linux.no/source/Documentation/CodingStyle... Затем посмотрите
		+	ссылки о том, как отправляются отдельные изменения (http://lxr.linux.no/source/Documentation/SubmittingPatches) и целые новые
		+	драйвера (http://lxr.linux.no/source/Documentation/SubmittingDrivers).
		+	\|Ширина=}}

	[[Категория:Специальный репортаж]]		[[Категория:Специальный репортаж]]