[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