[devel] Re: coldplug/warmplug

Michael Shigorin =?iso-8859-1?q?mike_=CE=C1_osdn=2Eorg=2Eua?=
Вт Авг 30 14:41:49 MSD 2005


On Tue, Aug 30, 2005 at 01:21:01PM +0400, Anton Farygin wrote:
> > > Проблема в том, что не годится инициализировать систему как
> > > livecd при каждой загрузке. И кстати, coldplug уже есть, я
> > > видел в SuSE.
> > Причём тут инициализация как livecd?

При том, что нет фиксации состояния и есть повышенная
неопределённость.  Администраторы *NIX склонны это воспринимать 
в штыки :-)

Денис, не тормози :-)

> > При каждой загрузки загружаются все модули из /etc/modules.
> > Кроме этого те модули, который с точки зрения libhw нужны, но
> > их нет -- дописываются в /etc/modules.
> Можно подробнее ? Какие модули прописываются и где их нет ?

Только лучше не /etc/modules, а что-то включаемое.

> > При штатной работе (без обновлений libhw, ядра, добавления
> > железа) coldplug не будет делать ничего.
> А когда он будет выполняться ?

Вместо kudzu, около (не знаю, перед/после) hotplug?

> Мне не совсем понятна схема его работы.

В hotplug@ вот чего надумали:

http://lists.osdn.org.ua/wws/arc/hotplug/2005-06/msg00006.html
http://lists.osdn.org.ua/wws/arc/hotplug/2005-06/msg00014.html
http://lists.osdn.org.ua/wws/arc/hotplug/2005-06/msg00017.html
http://lists.osdn.org.ua/wws/arc/hotplug/2005-08/msg00002.html

> Что будет происходить в случае, когда:

И придумали схему, когда:

> - модуль переименовался в новом ядре

Перестраивается кэш соответствий ID<->modname

> - модуль исчез в новом ядре

Предполагается кэш с учётом `uname -r`, так что обновление ядра
автоматически приводит к инвалидации /кэша/.

> - сменили железо
> - удалили железо
> - добавили железо

Комбинация инициализации "как обычно" и исчезновения модуля
(ломание мостика ID<->modname)

> и т.д.

И т.п.

> Что будет делаться для:
> - не PCI устройств (PNP, USB, CPU и т.д.)

ISA PnP -- я склонен фиксировать конфигурацию и изменения
производить исключительно пинком обновлялки (ср. sndconfig).
Потому что дорого по времени и более чревато зависаниями.

CPU -- не знаю, не требовалось.

USB -- как раз территория _hotplug_.  См. третью ссылку из пачки
выше.

> - упорядочивания загрузки модулей (актуально для USB, например)

Для PCI тоже актуально (звук/сеть; обсуждение -- ссылки выше):

https://bugzilla.altlinux.org/show_bug.cgi?id=7085
https://bugzilla.altlinux.org/show_bug.cgi?id=6830

На самом деле может ещё потребоваться "дробный" *plug -- с тем,
чтобы на стадии "доступен /" иметь списки драйверов (кэш), но
инициировать загрузку их из соответствующих rc/initscripts.

Это может помочь решить проблемы:

- необходимость /usr для настроечных скриптов подсистемы, который
  бывает сетевой (для чего нужен загруженный модуль интерфейса и 
  отработавший ifup);
- один из втыкаемых hotplug "по площади" модулей вешает систему
  (отключение сервиса);
- недостаточной управляемости (тот же порядок устройств) и
  перегруженности системы невостребованными модулями.

Не уверен, что не создаст больше проблем, это сырая мысль,
которая возникла только что (но вспоминая обсуждение темы
USB-устройств и /usr в alsa-devel@).

> - добавления параметров модулям

Автоматического -- можно в кэш-файл (заодно изменение
автонастроек сможет производиться обновлением ядра).

Ручного -- чем-то, куда modprobe смотрит после кэша.

> и т.д.


PS: время на эту подсистему выделить можно, только если мы этим
будем заниматься не когда нам удобно, то надо бы понять сроки и
задачи, которые берёмся порешать.  Всё на вчера -- не бывает,
а Дед Лайн, про которого я слышал, был на днях.

-- 
 ---- WBR, Michael Shigorin <mike на altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/



Подробная информация о списке рассылки Devel