Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Wed, 9 Jan 2002 15:53:45 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Wed, 9 Jan 2002 15:53:36 -0500 Received: from air-1.osdl.org ([65.201.151.5]:14468 "EHLO segfault.osdlab.org") by vger.kernel.org with ESMTP id ; Wed, 9 Jan 2002 15:53:25 -0500 Date: Wed, 9 Jan 2002 12:55:29 -0800 (PST) From: Patrick Mochel X-X-Sender: To: "Eric S. Raymond" cc: , , Subject: Re: initramfs programs (was [RFC] klibc requirements) In-Reply-To: <200201092005.g09K5OL28043@snark.thyrsus.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 9 Jan 2002, Eric S. Raymond wrote: > greg k-h: > >What does everyone else need/want there? > > dmidecode, so the init script can dump a DMI report in a known > location such as /var/run/dmi. Why do you need that during that stage of the boot process? The DMI tables won't go away. Besides, is there a way to put them in such a place that when mounting the real root partition, they won't go away? Or, is the initramfs partition going to persist during runtime? However, we may needs parsers to do IRQ routing. Yes, that means (dramatic horror music) an ACPI interpreter and/or PIRQ table parser. Which brings me to the question about initramfs configurability. Different systems have different needs during that process. It seems that we need a generic way to build applications for initramfs (and link them against the libc that's used) and build initramfs images. If building the image is part of the kernel build process, then it's not an issue. But, it would be nice, IMHO, to separate the two; so you could build a new initramfs image and tack it on to an already built kernel... -pat - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/