* [d-kernel] Вынос IDE в модуль @ 2005-02-05 14:50 Vitaly Lipatov 2005-02-07 9:42 ` Sergey Vlasov 0 siblings, 1 reply; 5+ messages in thread From: Vitaly Lipatov @ 2005-02-05 14:50 UTC (permalink / raw) To: devel-kernel А какие у нас остались аргументы в пользу того, чтобы (для ядра 2.6.х) по-прежнему держать IDE вкомпилированным в ядро? Предлагается вынести его в отдельный модуль. -- Lav Виталий Липатов Санкт-Петербург GNU! ALT Linux Team! LaTeX! LyX! ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [d-kernel] Вынос IDE в модуль 2005-02-05 14:50 [d-kernel] Вынос IDE в модуль Vitaly Lipatov @ 2005-02-07 9:42 ` Sergey Vlasov 2005-02-07 22:47 ` Vitaly Lipatov 0 siblings, 1 reply; 5+ messages in thread From: Sergey Vlasov @ 2005-02-07 9:42 UTC (permalink / raw) To: devel-kernel [-- Attachment #1: Type: text/plain, Size: 736 bytes --] On Sat, Feb 05, 2005 at 05:50:34PM +0300, Vitaly Lipatov wrote: > А какие у нас остались аргументы в пользу того, > чтобы (для ядра 2.6.х) по-прежнему держать IDE > вкомпилированным в ядро? > Предлагается вынести его в отдельный модуль. Это уже давно предлагается; основная сложность тут в написании соответствующей поддержки для mkinitrd. Сейчас у меня есть вроде бы работающий кусок, определяющий набор модулей для PCI IDE, обнаруженных текущим ядром. Правда, в случае, если в старом ядре не было нужного драйвера, из-за чего использовался ide-generic, появившийся в новом ядре драйвер не будет использован автоматически. Видимо, стоит ещё добавить поиск PCI IDE, которые могут оказаться на ide-generic, по классу. [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [d-kernel] Вынос IDE в модуль 2005-02-07 9:42 ` Sergey Vlasov @ 2005-02-07 22:47 ` Vitaly Lipatov 2005-02-08 11:16 ` Sergey Vlasov 0 siblings, 1 reply; 5+ messages in thread From: Vitaly Lipatov @ 2005-02-07 22:47 UTC (permalink / raw) To: devel-kernel 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? > Правда, в случае, если в старом ядре не было нужного драйвера, > из-за чего использовался ide-generic, появившийся в новом ядре Да, это я ловил, делая initrd для ядра 2.6 из 2.4 Но может это исправляется просто загрузочным CD с ядром 2.6? > драйвер не будет использован автоматически. Видимо, стоит ещё > добавить поиск PCI IDE, которые могут оказаться на > ide-generic, по классу. -- Lav Виталий Липатов Санкт-Петербург GNU! ALT Linux Team! LaTeX! LyX! ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [d-kernel] Вынос IDE в модуль 2005-02-07 22:47 ` Vitaly Lipatov @ 2005-02-08 11:16 ` Sergey Vlasov 2005-02-08 12:58 ` [d-kernel] ÷ÙÎÏÓ IDE × ÍÏÄÕÌØ Anton Farygin 0 siblings, 1 reply; 5+ messages in thread From: Sergey Vlasov @ 2005-02-08 11:16 UTC (permalink / raw) To: devel-kernel [-- Attachment #1: Type: text/plain, Size: 2857 bytes --] 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, и в этом месте его загружать не надо. [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [d-kernel] ÷ÙÎÏÓ IDE × ÍÏÄÕÌØ 2005-02-08 11:16 ` Sergey Vlasov @ 2005-02-08 12:58 ` Anton Farygin 0 siblings, 0 replies; 5+ messages in thread From: Anton Farygin @ 2005-02-08 12:58 UTC (permalink / raw) To: ALT Linux kernel packages development 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2005-02-08 12:58 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2005-02-05 14:50 [d-kernel] Вынос IDE в модуль Vitaly Lipatov 2005-02-07 9:42 ` Sergey Vlasov 2005-02-07 22:47 ` Vitaly Lipatov 2005-02-08 11:16 ` Sergey Vlasov 2005-02-08 12:58 ` [d-kernel] ÷ÙÎÏÓ IDE × ÍÏÄÕÌØ Anton Farygin
ALT Linux kernel packages development This inbox may be cloned and mirrored by anyone: git clone --mirror http://lore.altlinux.org/devel-kernel/0 devel-kernel/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 devel-kernel devel-kernel/ http://lore.altlinux.org/devel-kernel \ devel-kernel@altlinux.org devel-kernel@altlinux.ru devel-kernel@altlinux.com public-inbox-index devel-kernel Example config snippet for mirrors. Newsgroup available over NNTP: nntp://lore.altlinux.org/org.altlinux.lists.devel-kernel AGPL code for this site: git clone https://public-inbox.org/public-inbox.git