Differences between revisions 2 and 8 (spanning 6 versions)
Revision 2 as of 2010-02-04 10:49:16
Size: 9549
Editor: VasilyValov
Comment:
Revision 8 as of 2012-03-03 18:21:49
Size: 13025
Comment: Add link to translations
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
#language ru
~-[[DebianWiki/EditorGuide#translation|Translation(s)]]: [[udev|English]] - [[fr/udev|Français]] - [[it/udev|Italiano]] - Русский-~
----
Line 3: Line 6:
Файловая система udev ("юдев") появилась в ядрах версии 2.6 [[LinuxKernel|kernel]] заместо [[DevFS]] ("дев фс") Файловая система udev ("юдев") появилась в [[LinuxKernel|ядрах]]  версии 2.6 заместо [[DevFS]] ("дев фс")
Line 5: Line 8:
В отличие от devfs, которая работает в пространстве ядра, udev работает в пространстве пользователя. Она динамически обновляет содержимое директори /dev , как и его предшественница sysfs ("сисфс"). Sysfs рассматривалась как полезный инструмент для разработки и существовала только в ядрах Линукс версии 2.5, и была замещена udev в ядре 2.6. В отличие от devfs, которая работает в пространстве ядра, udev работает в пространстве пользователя. Она динамически обновляет содержимое директории /dev , как и его предшественница sysfs ("сисфс"). Sysfs рассматривалась как полезный инструмент для разработки и существовала только в ядрах Линукс версии 2.5, и была замещена udev в ядре 2.6.
Line 7: Line 10:
udev позволяет назначать постоянные имена для устройств. Например, можно создать правило для монтирования жесткого диска производителем которого является "iRiver" с кодом устройства "ABC", как устройство /dev/iriver. Постоянность в названии устройств гарантирует, что все скрипты, зависящие от присутствия в системе определённых устройст, будут работать правильно. udev позволяет назначать постоянные имена для устройств. Например, можно создать правило для монтирования жесткого диска производителем которого является "iRiver" с кодом устройства "ABC", как устройство /dev/iriver. Постоянность в названии устройств гарантирует, что все скрипты, зависящие от присутствия в системе определённых устройств, будут работать правильно.
Line 12: Line 15:
udev состоит из нескольких сервисов ядра и демона (процесса) udevd. Ядро сообщает демону udevd о наступлении определенного события. Сам демон udevd реагирует на наступившее событие через actions ("действия"). Информация о событии поступает от ядра. Все действия происходят в пользовательском окружении. ''Можно ли сделать так, чтобы от ядра передавалась только определенная информация о событии ?'' Можно настраивать действия на наступившее событие через "rules" ("правила"). udev состоит из нескольких сервисов ядра и демона (процесса) udevd. Ядро сообщает демону udevd о наступлении определённого события. Сам демон udevd реагирует на наступившее событие через actions ("действия"). Информация о событии поступает от ядра. Все действия происходят в пользовательском окружении. ''Можно ли сделать так, чтобы от ядра передавалась только определенная информация о событии ?'' Можно настраивать действия на наступившее событие через "rules" ("правила").
Line 14: Line 17:
Демон udevd запускается скриптом {{{/etc/rcS.d/udev}}}. Файл конфигурации находится в {{{/etc/udev/udev.conf}}}. Файл правил для более полной настройки демона udevd лежит в {{{/etc/udev/rules.d}}}.
Файлы находящиеся в данной директории оканчивающиеся на ".rules" парсятся в алфавитном порядке. При изменении конфигурационного файла или файла правил, демон udevd следует перезапускать.
Line 15: Line 20:
The udevd daemon, like other daemons, starts on boot because of an init script: {{{/etc/rcS.d/udev}}}. Its config file is in {{{/etc/udev/udev.conf}}}. The rules files (which amount to more configuration for udevd) are taken from {{{/etc/udev/rules.d}}}. Files in there are parsed in alpha order, as long as the name ends with ".rules". When the config file or rules files are changed, then the udevd daemon should be restarted (or, as mentioned further down this page, you can use the udevtest program). Множество файлов, находящихся в директории {{{/etc/udev/rules.d}}}, ссылаются на другие файлы. Можно предположить, что при редактировании файлов правил, текстовый редактор сделает работоспособные резервные копии, которые можно будет использовать при следующем запуске udevd. Поскольку имена ссылок могут отличаться от имён исходных файлов, они могут быть упорядочены без опасений.
Line 17: Line 22:
Many of the files in {{{/etc/udev/rules.d}}} are links to files elsewhere. ''I'm guessing'' that's so that when the rules files are edited, the editor backups aren't left lying around where they might be used in the next restart of the udevd daemon. Also, since the links can have different names from the original files, then they can be ordered without having to worry about what names they have (as with the init scripts). udev был создан для реагирования на события типа "горячего подключения". Большая часть документации касается создания файлов устройств для новых физических устройств появившихся в системе. Однако udev не является узкоспециализированным. Он может запускать любую команду пользовательского режима в ответ на обнаружение нового устройства или любого другого события, полученного от ядра.
Line 19: Line 24:
udev was created to respond to hotplug type of events. Much documentation refers to creating devices in response to new devices that have appeared. But, udev is more general; it can run arbitrary userspace commands in response to a new device appearing - or to whatever events it receives from the kernel. Когда работает udevd:
Line 21: Line 26:
The times when udevd is active are:  1. при загрузке он парсит все конфигурационные файлы и файлы правил и создаёт в памяти базу данных правил
 2. при появлении события. Он проверяет свою базу данных правил и осуществляет соответствующие действия.
Line 23: Line 29:
 1. at startup, it parses all the config files and rule files and builds a rules database in memory.
 1. When an event happens, it checks its rule database and performs the appropriate actions.
<<Anchor(Правила)>>
=== Правила ===
Line 26: Line 32:
<<Anchor(rules)>>
=== Rules ===

Rules for rules:
 1. rules are all on one line (lines can be broken with \ just before newline)
 1. rules consist of "matches" and "actions"
 1. matches and actions are "key" "operator" "value" triplets
 1. matches have == or != for operator
 1. actions have = (assignment) for operator
 1. matches check one or more attributes of the event to see if the action will be applied
 1. actions specify what will happen
 1. example match: {{{BUS=="usb"}}}
 1. example action: {{{NAME="mydev"}}}
 1. example rule: {{{
Правила для правил:
 1. правила пишутся в одну строку. Строка может быть разбита символом \ после которого сразу идёт символ новой строки (клавиша Enter)
 2. правила состоят из "matches" (соответствий) и "actions" (действий)
 3. matches и actions - это триплеты "key"(ключ) "operator"(оператор) "value" (значение)
 4. matches (соответствия) имеют оператор == или !=
 5. actions (действия) имеют оператор = (оператор присваивания)
 6. соответствия (matches) проверяют один или более атрибутов события для определения необходимости выполнения действия.
 7. действия (actions) указывают на то, что должно происходить
 8. пример соответствия (match): {{{BUS=="usb"}}}
 9. пример действия (action): {{{NAME="mydev"}}}
 10. пример правила (rule): {{{
Line 43: Line 46:
 1. all matching rules will fire
 1. earlier rules have precedence over later rules - so put your customizations early in the rules.d file list
 1. actions like key="value" override
 1. actions like key+="value" add to the actions that are executed, eg {{{SYMLINK+="foo"}}} means "in addition to any other symlinks you were going to make for this event, also make one called foo"
 11. все подходящие правила будут применены
 12. предшествующие правила имеют приоритет над последующими, поэтому помещайте свои изменения в список файлов, находящийся в rules.d
 13. действия (action) вида key="value" перезаписываются
 14. действия (action) вида key+="value" добавляются к существующим. Например, {{{SYMLINK+="foo"}}} означает, что в дополнение к любым другим symlinks ("симлинкс"), которые должны быть выполнены для данного события, также следует выполнить foo. ("фуу")
Line 48: Line 51:
<<Anchor(rulesets)>>
=== Rule sets ===
<<Anchor(Множество правил)>>
=== Множество правил ===
Line 51: Line 54:
Rules for rule sets:
 1. All the rules are in one big rule space, although they are divided into several files.
 1. The only organization in the rule space is the ability to set labels, and then to skip a bunch of rules during "match this event to rules" time by jumping forward with a {{{GOTO}}} action.
 1. there is one other rule type called a label: eg {{{LABEL="persistent_storage_end"}}} These are used by regular rules that have "GOTO" actions, eg: {{{
Правила для множества правил:
 1. Все правила находятся в одном пространстве, хотя и располагаются в нескольких файлах.
 2. В этом пространстве имеется возможность создавать метки и с их помощью пропускать некоторое количество правил, в зависимости от условия. Это осуществляется с помощью действия ("action") {{{GOTO}}}
 3. Также существует ещё один тип правил, называемый меткой. Например, {{{LABEL="persistent_storage_end"}}}. Этот тип используется в обычных правилах с действием "GOTO"("гоуту"), например {{{
Line 56: Line 59:
}}} Note that in this rule, the term ACTION is an attribute of an event and is being used as a condition for deciding if the GOTO action will be triggered.
 1. It is polite to keep GOTOs to jump within a file (or you will have to worry about reordering the files)
 1. Don't jump backwards to a label (didn't try it, but imagine it might end in an infinite loop? Maybe the udev code checks for that - but if it's going to be ignored (at best) why bother?)
 1. You can set variables in ENV space in earlier rules and refer to them with later rules
 1. The facility for dynamic rule creation exists (example: see {{{z45_persistent-net-generator.rules}}})
}}} . Обратите внимание, что ACTION (действие) является атрибутом события и используется в качестве предусловия для выполнения действия GOTO.
 4. Использование GOTO для "прыжков" в рамках одного файла вполне нормально. Если же Вы используете GOTO для "прыжков" между файлами, то Вам следует думать о том, что порядок файлов может быть изменён.
 5. Не возвращайтесь обратно на "метку". Это может привести к бесконечному циклу.
 6. Вы можете установить переменную среды ENV в ранних правилах, а затем ссылаться на неё в последующих.
 7. Существуют средства для динамического создания правил. Пример смотрите {{{z45_persistent-net-generator.rules}}}
Line 62: Line 65:
<<Anchor(blacklisting)>>
== Blacklisting ==
<<Anchor(Чёрные списки)>>
== Чёрные списки ==
Line 68: Line 71:
<<Anchor(persistent-name)>>
== Persistent Device name ==
In this example, we want to make sure your 3G card get a persistent name.
<<Anchor(Постоянные имена)>>
== Постоянное имя устройства ==
В данном примере, мы дадим постоянное имя для 3G модема.
Line 72: Line 75:
1. Plug the "card" (or device)
2. run the following command, on the proper device :
1. Подсоедините устройство.
2. Выполните следующую команду на соответствующем устройстве:
Line 144: Line 148:
3. Create a file in /etc/udev/rules.d, typically named {{{z21_persistent-local.rules}}}. 3. Создайте файл в /etc/udev/rules.d и назовите его {{{z21_persistent-local.rules}}}.
Line 151: Line 155:
4. Перезапустите скрипты (или выполните перезагрузку ;``)
Line 152: Line 157:
4. Force re-running the scripts (or reboot ;``)
Line 158: Line 162:
a more detailed example by [[http://linux.derkeiler.com/Newsgroups/comp.os.linux.questions/2007-10/msg00000.html|semu5 on comp.os.linux.questions]]. There is also a [[http://reactivated.net/writing_udev_rules.html|Writing udev rules]]. более подробный пример [[http://linux.derkeiler.com/Newsgroups/comp.os.linux.questions/2007-10/msg00000.html|semu5 on comp.os.linux.questions]]. А также [[http://reactivated.net/writing_udev_rules.html|Написание udev правил]].
Line 160: Line 164:
== References ==
 * DeviceManagement under Debian/Linux
 * [[http://reactivated.net/writing_udev_rules.html]] - Writing udev rules
== Ссылки ==
 * Управление устройствами в Debian/Linux
 * [[http://reactivated.net/writing_udev_rules.html]] - написание правил для udev

Translation(s): English - Français - Italiano - Русский


FileSystem


Файловая система udev ("юдев") появилась в ядрах версии 2.6 заместо DevFS ("дев фс")

В отличие от devfs, которая работает в пространстве ядра, udev работает в пространстве пользователя. Она динамически обновляет содержимое директории /dev , как и его предшественница sysfs ("сисфс"). Sysfs рассматривалась как полезный инструмент для разработки и существовала только в ядрах Линукс версии 2.5, и была замещена udev в ядре 2.6.

udev позволяет назначать постоянные имена для устройств. Например, можно создать правило для монтирования жесткого диска производителем которого является "iRiver" с кодом устройства "ABC", как устройство /dev/iriver. Постоянность в названии устройств гарантирует, что все скрипты, зависящие от присутствия в системе определённых устройств, будут работать правильно.

Обзор

udev состоит из нескольких сервисов ядра и демона (процесса) udevd. Ядро сообщает демону udevd о наступлении определённого события. Сам демон udevd реагирует на наступившее событие через actions ("действия"). Информация о событии поступает от ядра. Все действия происходят в пользовательском окружении. Можно ли сделать так, чтобы от ядра передавалась только определенная информация о событии ? Можно настраивать действия на наступившее событие через "rules" ("правила").

Демон udevd запускается скриптом /etc/rcS.d/udev. Файл конфигурации находится в /etc/udev/udev.conf. Файл правил для более полной настройки демона udevd лежит в /etc/udev/rules.d. Файлы находящиеся в данной директории оканчивающиеся на ".rules" парсятся в алфавитном порядке. При изменении конфигурационного файла или файла правил, демон udevd следует перезапускать.

Множество файлов, находящихся в директории /etc/udev/rules.d, ссылаются на другие файлы. Можно предположить, что при редактировании файлов правил, текстовый редактор сделает работоспособные резервные копии, которые можно будет использовать при следующем запуске udevd. Поскольку имена ссылок могут отличаться от имён исходных файлов, они могут быть упорядочены без опасений.

udev был создан для реагирования на события типа "горячего подключения". Большая часть документации касается создания файлов устройств для новых физических устройств появившихся в системе. Однако udev не является узкоспециализированным. Он может запускать любую команду пользовательского режима в ответ на обнаружение нового устройства или любого другого события, полученного от ядра.

Когда работает udevd:

  1. при загрузке он парсит все конфигурационные файлы и файлы правил и создаёт в памяти базу данных правил
  2. при появлении события. Он проверяет свою базу данных правил и осуществляет соответствующие действия.

Правила

Правила для правил:

  1. правила пишутся в одну строку. Строка может быть разбита символом \ после которого сразу идёт символ новой строки (клавиша Enter)
  2. правила состоят из "matches" (соответствий) и "actions" (действий)
  3. matches и actions - это триплеты "key"(ключ) "operator"(оператор) "value" (значение)
  4. matches (соответствия) имеют оператор == или !=
  5. actions (действия) имеют оператор = (оператор присваивания)
  6. соответствия (matches) проверяют один или более атрибутов события для определения необходимости выполнения действия.
  7. действия (actions) указывают на то, что должно происходить
  8. пример соответствия (match): BUS=="usb"

  9. пример действия (action): NAME="mydev"

  10. пример правила (rule):

    KERNEL=="sd*[0-9]|dasd*[0-9]", ENV{ID_SERIAL}=="?*", \
            SYMLINK+="disk/by-id/$env{ID_BUS}-$env{ID_SERIAL}-part%n"
  11. все подходящие правила будут применены
  12. предшествующие правила имеют приоритет над последующими, поэтому помещайте свои изменения в список файлов, находящийся в rules.d
  13. действия (action) вида key="value" перезаписываются
  14. действия (action) вида key+="value" добавляются к существующим. Например, SYMLINK+="foo" означает, что в дополнение к любым другим symlinks ("симлинкс"), которые должны быть выполнены для данного события, также следует выполнить foo. ("фуу")

Множество правил

Правила для множества правил:

  1. Все правила находятся в одном пространстве, хотя и располагаются в нескольких файлах.
  2. В этом пространстве имеется возможность создавать метки и с их помощью пропускать некоторое количество правил, в зависимости от условия. Это осуществляется с помощью действия ("action") GOTO

  3. Также существует ещё один тип правил, называемый меткой. Например, LABEL="persistent_storage_end". Этот тип используется в обычных правилах с действием "GOTO"("гоуту"), например

    ACTION!="add", GOTO="persistent_storage_end"
    . Обратите внимание, что ACTION (действие) является атрибутом события и используется в качестве предусловия для выполнения действия GOTO.
  4. Использование GOTO для "прыжков" в рамках одного файла вполне нормально. Если же Вы используете GOTO для "прыжков" между файлами, то Вам следует думать о том, что порядок файлов может быть изменён.
  5. Не возвращайтесь обратно на "метку". Это может привести к бесконечному циклу.
  6. Вы можете установить переменную среды ENV в ранних правилах, а затем ссылаться на неё в последующих.
  7. Существуют средства для динамического создания правил. Пример смотрите z45_persistent-net-generator.rules

Чёрные списки

KernelModuleBlacklisting

Постоянное имя устройства

В данном примере, мы дадим постоянное имя для 3G модема.

1. Подсоедините устройство. 2. Выполните следующую команду на соответствующем устройстве:

  • $udevinfo -a -p $(udevinfo -q path -n /dev/ttyS1)
    
    Udevinfo starts with the device specified by the devpath and then
    walks up the chain of parent devices. It prints for every device
    found, all possible attributes in the udev rules key format.
    A rule to match, can be composed by the attributes of the device
    and the attributes from one single parent device.
    
      looking at device '/class/tty/ttyS1':
        KERNEL=="ttyS1"
        SUBSYSTEM=="tty"
        DRIVER==""
        ATTR{dev}=="4:65"
    
      looking at parent device '/devices/pci0000:00/0000:00:1e.0/0000:15:00.0/0.0':
        KERNELS=="0.0"
        SUBSYSTEMS=="pcmcia"
        DRIVERS=="serial_cs"
        ATTRS{modalias}=="pcmcia:m00A4c1AAFf02fn00pfn00pa32607776pbD9E73B13pcAF9C4D7Fpd00000000"
        ATTRS{prod_id3}=="NRM6831"
        ATTRS{prod_id2}=="Merlin UMTS Modem"
        ATTRS{prod_id1}=="Novatel Wireless"
        ATTRS{card_id}=="0x1aaf"
        ATTRS{manf_id}=="0x00a4"
        ATTRS{func_id}=="0x02"
        ATTRS{pm_state}=="on"
        ATTRS{function}=="0x00"
    
      looking at parent device '/devices/pci0000:00/0000:00:1e.0/0000:15:00.0':
        KERNELS=="0000:15:00.0"
        SUBSYSTEMS=="pci"
        DRIVERS=="yenta_cardbus"
        ATTRS{msi_bus}=="1"
        ATTRS{broken_parity_status}=="0"
        ATTRS{enable}=="2"
        ATTRS{numa_node}=="0"
        ATTRS{modalias}=="pci:v00001180d00000476sv000017AAsd000020C6bc06sc07i00"
        ATTRS{local_cpus}=="00000003"
        ATTRS{irq}=="16"
        ATTRS{class}=="0x060700"
        ATTRS{subsystem_device}=="0x20c6"
        ATTRS{subsystem_vendor}=="0x17aa"
        ATTRS{device}=="0x0476"
        ATTRS{vendor}=="0x1180"
    
      looking at parent device '/devices/pci0000:00/0000:00:1e.0':
        KERNELS=="0000:00:1e.0"
        SUBSYSTEMS=="pci"
        DRIVERS==""
        ATTRS{msi_bus}=="1"
        ATTRS{broken_parity_status}=="0"
        ATTRS{enable}=="1"
        ATTRS{numa_node}=="0"
        ATTRS{modalias}=="pci:v00008086d00002448sv00000000sd00000000bc06sc04i01"
        ATTRS{local_cpus}=="00000003"
        ATTRS{irq}=="0"
        ATTRS{class}=="0x060401"
        ATTRS{subsystem_device}=="0x0000"
        ATTRS{subsystem_vendor}=="0x0000"
        ATTRS{device}=="0x2448"
        ATTRS{vendor}=="0x8086"
    
      looking at parent device '/devices/pci0000:00':
        KERNELS=="pci0000:00"
        SUBSYSTEMS==""
        DRIVERS==""
        ATTRS{uevent}==""

3. Создайте файл в /etc/udev/rules.d и назовите его z21_persistent-local.rules.

ATTRS{prod_id2}=="Merlin UMTS Modem", ATTRS{prod_id1}=="Novatel Wireless", SYMLINK+="MerlinUMTS"
## Alternatively we could use :
# ATTRS{card_id}=="0x1aaf", ATTRS{manf_id}=="0x00a4", SYMLINK+="MerlinUMTS"

4. Перезапустите скрипты (или выполните перезагрузку ;)

udevtest  $(udevinfo -q path -n /dev/ttyS1) --force

более подробный пример semu5 on comp.os.linux.questions. А также Написание udev правил.

Ссылки


CategorySystemAdministration | ?CategoryLocalResourcesManagement