From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Message-ID: <4208B776.9090608@altlinux.com> Date: Tue, 08 Feb 2005 15:58:30 +0300 From: Anton Farygin User-Agent: Mozilla Thunderbird 1.0 (X11/20050127) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ALT Linux kernel packages development Subject: Re: [d-kernel] =?UTF-8?B?w7fDmcOOw4/DkyBJREUgw5cgw43Dj8OEw5XDjMOY?= References: <200502051750.35565.lav@altlinux.ru> <20050207094216.GV11017@master.mivlgu.local> <200502080147.55822.lav@altlinux.ru> <20050208111624.GB24459@master.mivlgu.local> In-Reply-To: <20050208111624.GB24459@master.mivlgu.local> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: devel-kernel@altlinux.ru X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ALT Linux kernel packages development List-Id: ALT Linux kernel packages development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2005 13:03:00 -0000 Archived-At: List-Archive: List-Post: Sergey Vlasov wrote: >On Tue, Feb 08, 2005 at 01:47:55AM +0300, Vitaly Lipatov wrote: > > >>On Monday 07 February 2005 12:42, Sergey Vlasov wrote: >> >> >>>On Sat, Feb 05, 2005 at 05:50:34PM +0300, Vitaly Lipatov wrote: >>> >>> >>>>А какие у нас остались аргументы в пользу того, >>>>чтобы (для ядра 2.6.х) по-прежнему держать IDE >>>>вкомпилированным в ядро? >>>>Предлагается вынести его в отдельный модуль. >>>> >>>> >>>Это уже давно предлагается; основная сложность тут в написании >>> >>> >>Куда FR повесить? >> >> > >В принципе уже не надо ;) > > > >>>соответствующей поддержки для mkinitrd. >>> >>> >>Сейчас в initrd толком не пакуется поддержка soft raid и >>sata-контроллеров, так что всё равно надо. И с учётом >>приближающейся повсеместной миграции на sata, приоритеты для ide >>теряюсь смысл. >> >> >>>Сейчас у меня есть вроде бы работающий кусок, определяющий >>>набор модулей для PCI IDE, обнаруженных текущим ядром. >>> >>> >>Здорово. А для sata? >> >> > >Поскольку драйверы SATA сейчас работают через эмуляцию SCSI, для них >используется тот же способ, что и для SCSI - загрузка модулей, >перечисленных в (alias|probeall) scsi_hostadapter ... в /etc/modules.conf. > > > >>>Правда, в случае, если в старом ядре не было нужного драйвера, >>>из-за чего использовался ide-generic, появившийся в новом ядре >>> >>> >>Да, это я ловил, делая initrd для ядра 2.6 из 2.4 >>Но может это исправляется просто загрузочным CD с ядром 2.6? >> >> > >То же самое вылезет и при обновлении ядра, если в предыдущей версии не >было нужного драйвера. Так что всё равно придётся что-то делать. > > > >>>драйвер не будет использован автоматически. Видимо, стоит ещё >>>добавить поиск PCI IDE, которые могут оказаться на >>>ide-generic, по классу. >>> >>> > >Тут вылезает ещё одна проблема - на таких PCI ID могут висеть ещё и >драйверы libata. А уж то, что сотворили в свежем sata_nv - вообще ужас: > >2005/01/20 achew | { PCI_VENDOR_ID_NVIDIA, PCI_ANY_ID, >2005/01/20 achew | PCI_ANY_ID, PCI_ANY_ID, >2005/01/20 achew | PCI_CLASS_STORAGE_IDE<<8, 0xffff00, GENERIC }, > >Т.е., этот модуль будет вытаскиваться при наличии _любого_ контроллера >IDE от nVidia, а дальше функция ->probe смотрит, похож ли этот контроллер >на SATA: > >2005/01/20 achew | // Make sure this is a SATA controller by counting the number of bars >2005/01/20 achew | // (NVIDIA SATA controllers will always have six bars). Otherwise, >2005/01/20 achew | // it's an IDE controller and we ignore it. >2005/01/20 achew | for (bar=0; bar<6; bar++) >2005/01/20 achew | if (pci_resource_start(pdev, bar) == 0) >2005/01/20 achew | return -ENODEV; > >По этому поводу приходит на ум только фильтрация по пути к модулю - >например, так: если в имени файла модуля или модулей, вытаскиваемых по >зависимостям, есть /kernel/drivers/scsi/ - это не драйвер IDE, и в этом >месте его загружать не надо. > > Мне все-таки кажется что надо расширять функциональность hwdatabase. Rgds, Rider