From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <ed@altlinux.ru>
X-Comment-To: Sergey Vlasov
To: ALT Linux kernel packages development <devel-kernel@altlinux.ru>
Subject: Re: [d-kernel] IDE modularization again
In-Reply-To: <20040216143315.GF7789@master.mivlgu.local> (Sergey Vlasov's
	message of "Mon, 16 Feb 2004 17:33:15 +0300")
References: <m365e74619.fsf@pc213.belcaf.minsk.by>
	<20040216120645.GI11571@master.altlinux.ru>
	<87lln3xl6w.fsf@pc347.belcaf.minsk.by>
	<20040216123810.GM11571@master.altlinux.ru>
	<8765e7xiqu.fsf@pc347.belcaf.minsk.by>
	<20040216134314.GV11571@master.altlinux.ru>
	<m3hdxr2k1h.fsf@pc213.belcaf.minsk.by>
	<20040216141247.GA11571@master.altlinux.ru>
	<m3d68f2jji.fsf@pc213.belcaf.minsk.by>
	<20040216143315.GF7789@master.mivlgu.local>
From: ed@altlinux.ru (Ed V. Bartosh)
Organization: ALT Linux
Date: Mon, 16 Feb 2004 17:12:16 +0200
Message-ID: <m38yj32h4f.fsf@pc213.belcaf.minsk.by>
User-Agent: Gnus/5.1002 (Gnus v5.10.2) XEmacs/21.4 (Portable Code, linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=koi8-r
Content-Transfer-Encoding: 8bit
X-BeenThere: devel-kernel@altlinux.ru
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: ALT Linux kernel packages development <devel-kernel@altlinux.ru>
List-Id: ALT Linux kernel packages development <devel-kernel.altlinux.ru>
List-Unsubscribe: <http://altlinux.ru/mailman/listinfo/devel-kernel>,
	<mailto:devel-kernel-request@altlinux.ru?subject=unsubscribe>
List-Archive: </pipermail/devel-kernel>
List-Post: <mailto:devel-kernel@altlinux.ru>
List-Help: <mailto:devel-kernel-request@altlinux.ru?subject=help>
List-Subscribe: <http://altlinux.ru/mailman/listinfo/devel-kernel>,
	<mailto:devel-kernel-request@altlinux.ru?subject=subscribe>
X-List-Received-Date: Mon, 16 Feb 2004 15:12:46 -0000
Archived-At: <http://lore.altlinux.org/devel-kernel/m38yj32h4f.fsf@pc213.belcaf.minsk.by/>
List-Archive: <http://lore.altlinux.org/devel-kernel/>
List-Post: <mailto:devel-kernel@altlinux.org>

Sergey Vlasov <vsu@altlinux.ru> writes:

>> По-моему это надуманые проблемы и modules.conf парсить - это
>> совершенно лишнее.
>
> Или в конце концов завести mkinitrd.conf?
Идея здравая. Но я поддерживаю ее не в части парсинга modules.conf, а
в части упоминания там модулей для включения/исключения в/из initrd,
чтобы руками каждый раз не указывать.

> Например, если автоматика будет загонять драйверы для всех
> SCSI-контроллеров в initrd, кто-то может захотеть, чтобы туда
> добавлялось не всё.  (Вот тут на одной машине есть AHA-2940 с
> выдернутым BIOS-ом - на нём магнитооптика висит, его родной setup
> почему-то не запускался, а тормоза при загрузке достали.)
По результатам разговоров на канале автоматика будет загонять все
модули только для fail-safe вариантов загрузки, то есть не всегда.
А так да :)

> "Пусть делает сам себе initrd" - конечно, в определённом смысле тоже
> решение, но это же неудобно (придётся об этом вспоминать при каждой
> смене ядра, или делать какой-то hook в скриптах).
Вот я и предлагаю для этого использовать mkinitrd.conf. но попозже, поскольку
это уже шашечки, а нам бы поехать для начала :)

-- 
Best regards,
Ed V. Bartosh