From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Injected-Via-Gmane: http://gmane.org/ To: sisyphus@lists.altlinux.org From: Anton Farygin Date: Wed, 12 Apr 2006 11:55:14 +0400 Organization: ALT Linux Ltd. Message-ID: References: <20060411162251.GA15449@procyon.home> <20060412072357.GA14438@procyon.home> Mime-Version: 1.0 Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: rider.balabanovo.ru User-Agent: Thunderbird 1.5 (X11/20060328) In-Reply-To: <20060412072357.GA14438@procyon.home> Sender: news Subject: Re: [sisyphus] Warning: udev-089 X-BeenThere: sisyphus@lists.altlinux.org X-Mailman-Version: 2.1.7 Precedence: list Reply-To: ALT Linux Sisyphus discussion list List-Id: ALT Linux Sisyphus discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2006 07:49:21 -0000 Archived-At: List-Archive: List-Post: Sergey Vlasov wrote: > On Wed, Apr 12, 2006 at 10:48:04AM +0400, Anton Farygin wrote: >> Sergey Vlasov wrote: >>> On Tue, Apr 11, 2006 at 05:42:17PM +0400, Anton Farygin wrote: >>>> В ftp://ftp.altlinux.ru/pub/people/rider/udev-089 лежат пакеты нового udev. >>>> >>>> Просьба всем, кто использует ядро 2.6.16 - поставить и сообщить мне об >>>> найденных ошибках. С ядрами < 2.6.16 новый udev работать не будет. >>>> >>>> Через пару дней это может добраться до Sisyphus - лучше проверить заранее. >>> Да, камнепад будет изрядный. >>> >>> 1. После вызова udevtrigger нужно дождаться завершения обработки >>> сгенерированных событий - иначе иногда при дальнейшей загрузке не >>> обнаруживается даже /dev/urandom. Правда, в этом месте есть >>> грабли: >>> >>> http://wiki.linuxfromscratch.org/lfs/ticket/1720 >>> http://permalink.gmane.org/gmane.linux.hotplug.devel/9711 >> Да, и это известно. Сейчас загрузка проходит нормально, а вот если >> запускать udevtrigger из rc.sysinit - то всё становится очень плохо. >> >>> 2. Большинство /etc/hotplug/*.rc (как минимум, pci.rc и usb.rc) после >>> установки этой версии udev становятся бесполезным балластом - >>> udevtrigger сам сгенерирует все нужные события (правда, в >>> неопределённом порядке). >> pci.rc и usb.rc помимо генерации событий ещё модули загружает. Впрочем я >> уже давно собирался перенести эту функциональность в отдельный пакет. > > Загружают модули на самом деле *.agent, которые всё равно вызываются > при обработке событий. В usb.rc остаётся нужным только монтирование > /proc/bus/usb (впрочем, разработчики ядра давно хотят объявить её > obsolete - вот /dev/usb/... уже есть, и новая версия libusb умеет > пользоваться этими устройствами, только нужно из > /etc/hotplug/*.usermap сделать набор правил для назначения прав > доступа средствами udev). да, это понятно что agent. Только вот всё-таки я бы хотел загрузку модулей каким-то образом упорядочить, а иначе сейчас опять полезут баги - кто раньше из звуковых загрузился. Или мы уже умеем определять приоритеты использования у звуковых карт ? > > Вот только у нас libusb какая-то древняя - надо обновить. Обновим. > >>> 3. В случае наличия нескольких сетевых плат перед установкой этого >>> udev крайне желательно установить etcnet и настроить /etc/iftab, >>> иначе потом придётся долго разбираться в перепутавшихся eth*. >>> Причём USE_HOTPLUG=yes тоже может не работать, пока из >>> /etc/hotplug/net.agent не будет удалён кусок: >>> >>> # Red Hat specific hack... >>> if [ -f /etc/redhat-release ]; then >>> # Don't do anything if the network is stopped >>> if [ ! -f /var/lock/subsys/network ]; then >>> exit 0 >>> fi >>> fi >>> >>> Иначе получается race - сетевое устройство вполне может быть >>> обнаружено раньше, чем запустится сервис network (точнее, если в >>> запуск udevd будет добавлено ожидание завершения обработки событий >>> от udevtrigger, устройства и будут обнаруживаться раньше). >> Это если мы service udevd вынесем в rc.sysinit. > > Это и сейчас есть - udevd запускается раньше network, просто крайне > маловероятно. ага. точно. > >> Но там race идёт похуже >> - например совершенно непонятно как дождаться появления устройств для / >> и для swap > > while ! [ -f "$root_dev" ]; do sleep 1; done ? Хм.. как-то это некрасиво - придётся фактически перед каждым устройством делать. Да и опять же - как быть в случае, если / вдруг перехал ? Или например раздел прописан по LABEL или UUID ? > >>> Впрочем, это тоже неправильно - получается, что сетевые интерфейсы >>> могут запускаться до завершения общей инициализации сети. >>> Возможно, придётся добавить в запуск etcnet вызов собственной >>> версии udevtrigger, генерирующей события только для >>> /sys/class/net/* (и убедиться, что повторяющиеся вызовы >>> ifup-removable не приводят к нежелательным эффектам). >> Сейчас при service udevd restart сеть пропадает (она у меня >> настраивается вручную). Наверное стоит посмотреть что там точно происходит. > > У меня не пропадает. Это понятно - твой etcnet так настроен. Rgds, Rider