[devel] service udevd stop?

[Alexey Morozov]

On Mon, Mar 28, 2005 at 12:36:13PM +0400, Valery V. Inozemtsev wrote:
> В сообщении от 28 Март 2005 12:33 Alexey Morozov написал(a):
> > On Sat, Mar 26, 2005 at 03:49:53PM +0300, Valery V. Inozemtsev wrote:
> > > вот сижу я щас смотрю на udev из FC3... нету там ни сервиса, ни тем более
> > > /dev на tmpfs. наводит меня это на грусные мысли...
> > А я еще периодически гляжу в их багзиллу ;-P.
> > Впрочем, конструктивная критика приветствуется.
> раскажи для начала несведующим зачем там tmpfs
1. не конфликтовать со статическим dev. Ничего в данный момент не мешает
_остановить_ сервис udevd, если кажется, что udev мешает жить, и вернуться
к старой доброй любимой /dev, созданной dev-X.Y.Z-altN.i586.rpm.
К тому же, если файл устройства существует с самого начала (т.е. его
создавал не udev), то перестают работать [некоторые] правила udev'ные,
например, про создание линков (на месте этого дивайса)

2. Чисто udev'ная система НЕ способна грузить модули по запросу.
В данный момент в ALT есть два решения: создавать "заранее
сконфигурированные" устройства (в /etc/udev/devices) и пользоваться
modules_lookup (с соответствующим патчем на tmpfs).

В FC пошли по первому пути, что, в общем, просто приводит к
дублированию информации и хоронит в пределе идею дин. /dev.

3. Всегда есть возможность НЕ использовать tmpfs (по крайней мере,
есть в >= alt3). См. параметр udev_tmpfs в udev.conf. Правда, о
работоспособности ничего не скажу, не пробовал ;-)

Вообще, говоря, по здравому размышлению, метод с tmpfs / lookup traps
работает не слишком здорово. Лучше бы иметь некоторую систему, подобную
хе-хе, старому devfsd, то есть, userland-демон, которому по named pipe /
u.d. socket поступают от ядра нотификации о том, что кто-то попытался
открыть несуществующий дивайс в /dev. Либо /dev должен базироваться
на специализированной FUSE-файлухе.

Подчеркну, что самому udev'у - пофиг на какой FS сидеть, главное, чтоб
там mknod и symlink можно было бы сделать ;-). Но вот для задачи
подгрузки модулей по открытию дивайса требуется некоторая... магия.
Завязанная, с одной стороны, на ядро, которое должно сообщать что
потребовался /dev/lp0, а с другой - на юзерлэнд, который мог бы
выполнять соответствующие действия.

Если у кого есть опыт программирования такой вот задачи (то есть, либо
devfsd-like, либо fuse с виртуализацией дивайсов) - буду признаетелен за
консультации (или, хе-хе, лучше готовый код). Если есть какие-либо другие
внятные предложения на этот повод - тоже, в общем, добро пожаловать.

Что касается _сервиса_ udevd. Демон udev действительно поднимается
(дергается hotplug'ом) _до_ поднятия соотв. сервиса (да и вообще до
переключения в нужный ранлевел), в пределе, стартует минимальная версия
прямо из initrd / early user level (у нас нет) Именно это и было причиной
того, что service udevd stop в alt1 не работала, т.к. искался конкретный pid,
пробитый в /var/run/... Отдельный же сервис требуется для того, чтобы
отработать все правила по монтированию tmpfs, созданию доп. дивайсов
итп итп. Поскольку я не стал на данном этапе модифицировать rc.sysinit,
то сервис - оптимальное средство сделать все эти действия.

----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя     : =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Тип     : application/pgp-signature
Размер  : 189 байтов
Описание: =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Url     : <http://lists.altlinux.org/pipermail/devel/attachments/20050328/595d1a54/attachment-0001.bin>