From initramfs-owner@vger.kernel.org Wed Dec 17 10:52:50 2008 Delivered-To: halfline@gmail.com Received: by 10.140.147.10 with SMTP id u10cs38343rvd; Wed, 17 Dec 2008 10:52:50 -0800 (PST) Received: by 10.90.26.10 with SMTP id 10mr626651agz.95.1229539969633; Wed, 17 Dec 2008 10:52:49 -0800 (PST) Return-Path: Received: from vger.kernel.org (vger.kernel.org [209.132.176.167]) by mx.google.com with ESMTP id 4si1712751yxj.8.2008.12.17.10.52.46; Wed, 17 Dec 2008 10:52:49 -0800 (PST) Received-SPF: pass (google.com: domain of initramfs-owner@vger.kernel.org designates 209.132.176.167 as permitted sender) client-ip=209.132.176.167; Authentication-Results: mx.google.com; spf=pass (google.com: domain of initramfs-owner@vger.kernel.org designates 209.132.176.167 as permitted sender) smtp.mail=initramfs-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751060AbYLQSwe (ORCPT + 4 others); Wed, 17 Dec 2008 13:52:34 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751250AbYLQSwd (ORCPT ); Wed, 17 Dec 2008 13:52:33 -0500 Received: from pfepa.post.tele.dk ([195.41.46.235]:51806 "EHLO pfepa.post.tele.dk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751060AbYLQSwd (ORCPT ); Wed, 17 Dec 2008 13:52:33 -0500 Received: from ravnborg.org (x1-6-00-1e-2a-84-ae-3e.k225.webspeed.dk [80.163.61.94]) by pfepa.post.tele.dk (Postfix) with ESMTP id 13687A50011 for ; Wed, 17 Dec 2008 19:52:31 +0100 (CET) Received: by ravnborg.org (Postfix, from userid 500) id ED4EA580D0; Wed, 17 Dec 2008 19:54:04 +0100 (CET) Date: Wed, 17 Dec 2008 19:54:04 +0100 From: Sam Ravnborg To: initramfs@vger.kernel.org Subject: initramfs overview? Message-ID: <20081217185404.GA6169@uranus.ravnborg.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Sender: initramfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: initramfs@vger.kernel.org X-Evolution-Source: imap://halfline@imap.gmail.com/ Content-Transfer-Encoding: 8bit Hi all. Anywhere I can find a good summary of the ideas behind the grand unified initrd/initramfs? I recall some blogs on kernel planet but wonder if there is something better. Just to give me (and others) a headstart on the issue. Sam -- To unsubscribe from this list: send the line "unsubscribe initramfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html From initramfs-owner@vger.kernel.org Wed Dec 17 11:07:13 2008 Delivered-To: halfline@gmail.com Received: by 10.140.147.10 with SMTP id u10cs39066rvd; Wed, 17 Dec 2008 11:07:13 -0800 (PST) Received: by 10.90.74.9 with SMTP id w9mr639779aga.93.1229540832785; Wed, 17 Dec 2008 11:07:12 -0800 (PST) Return-Path: Received: from vger.kernel.org (vger.kernel.org [209.132.176.167]) by mx.google.com with ESMTP id 33si5611032yxr.12.2008.12.17.11.07.09; Wed, 17 Dec 2008 11:07:12 -0800 (PST) Received-SPF: pass (google.com: domain of initramfs-owner@vger.kernel.org designates 209.132.176.167 as permitted sender) client-ip=209.132.176.167; Authentication-Results: mx.google.com; spf=pass (google.com: domain of initramfs-owner@vger.kernel.org designates 209.132.176.167 as permitted sender) smtp.mail=initramfs-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751395AbYLQTHE (ORCPT + 4 others); Wed, 17 Dec 2008 14:07:04 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751360AbYLQTHE (ORCPT ); Wed, 17 Dec 2008 14:07:04 -0500 Received: from bombadil.infradead.org ([18.85.46.34]:59163 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751336AbYLQTHD (ORCPT ); Wed, 17 Dec 2008 14:07:03 -0500 Received: from hch by bombadil.infradead.org with local (Exim 4.68 #1 (Red Hat Linux)) id 1LD1jZ-0006G7-5y; Wed, 17 Dec 2008 19:07:01 +0000 Date: Wed, 17 Dec 2008 14:07:01 -0500 From: Christoph Hellwig To: initramfs@vger.kernel.org Cc: linux-kernel@vger.kernel.org, Kay Sievers , Dave Jones , cjwatson@ubuntu.com, Hannes Reinecke Subject: Re: Dracut -- Cross distribution initramfs infrastructure Message-ID: <20081217190700.GA15377@infradead.org> References: <1229540094.28858.150.camel@aglarond.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1229540094.28858.150.camel@aglarond.local> User-Agent: Mutt/1.5.18 (2008-05-17) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html Sender: initramfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: initramfs@vger.kernel.org X-Evolution-Source: imap://halfline@imap.gmail.com/ Content-Transfer-Encoding: 8bit On Wed, Dec 17, 2008 at 01:54:54PM -0500, Jeremy Katz wrote: > As davej started talking about a few months ago at Kernel Summit and > LPC, there's a lot of duplication between distros on the tools used to > generate the initramfs as well as the contents and how the initramfs > works. Ultimately, there's little reason for this not to be something > that is shared and worked on by everyone. Added to this is the fact > that everyone's infrastructures for this have grown up over a long-ish > period of time without significant amounts of reworking for the way that > the kernel and early boot works these days. > > Therefore I've started on a new project, dracut, to try to be a new > initramfs tool that can be used across various distributions. From the > README... It looks like Hannes has also been working on a new, modular initramfs for a while: http://git.kernel.org/?p=linux/kernel/git/hare/mkinitrd.git;a=summary I hope you guys can get together and agree on one implementation.. -- To unsubscribe from this list: send the line "unsubscribe initramfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html From initramfs-owner@vger.kernel.org Wed Dec 17 10:57:32 2008 Delivered-To: halfline@gmail.com Received: by 10.140.147.10 with SMTP id u10cs38561rvd; Wed, 17 Dec 2008 10:57:32 -0800 (PST) Received: by 10.214.181.12 with SMTP id d12mr1330075qaf.140.1229540251405; Wed, 17 Dec 2008 10:57:31 -0800 (PST) Return-Path: Received: from vger.kernel.org (vger.kernel.org [209.132.176.167]) by mx.google.com with ESMTP id 30si5475157yxk.57.2008.12.17.10.57.28; Wed, 17 Dec 2008 10:57:31 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of initramfs-owner@vger.kernel.org designates 209.132.176.167 as permitted sender) client-ip=209.132.176.167; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of initramfs-owner@vger.kernel.org designates 209.132.176.167 as permitted sender) smtp.mail=initramfs-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750855AbYLQS51 (ORCPT + 4 others); Wed, 17 Dec 2008 13:57:27 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751099AbYLQS51 (ORCPT ); Wed, 17 Dec 2008 13:57:27 -0500 Received: from mx2.redhat.com ([66.187.237.31]:45303 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750855AbYLQS50 (ORCPT ); Wed, 17 Dec 2008 13:57:26 -0500 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id mBHIvOou021794; Wed, 17 Dec 2008 13:57:24 -0500 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id mBHIvNF0022810; Wed, 17 Dec 2008 13:57:24 -0500 Received: from [10.11.13.109] (vpn-13-109.rdu.redhat.com [10.11.13.109]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id mBHIvMY8017887; Wed, 17 Dec 2008 13:57:22 -0500 Subject: Dracut -- Cross distribution initramfs infrastructure From: Jeremy Katz Reply-To: initramfs@vger.kernel.org To: initramfs@vger.kernel.org Cc: linux-kernel@vger.kernel.org, Kay Sievers , Dave Jones , cjwatson@ubuntu.com Content-Type: text/plain Date: Wed, 17 Dec 2008 13:54:54 -0500 Message-Id: <1229540094.28858.150.camel@aglarond.local> Mime-Version: 1.0 X-Scanned-By: MIMEDefang 2.58 on 172.16.27.26 Sender: initramfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: initramfs@vger.kernel.org X-Evolution-Source: imap://halfline@imap.gmail.com/ Content-Transfer-Encoding: 8bit As davej started talking about a few months ago at Kernel Summit and LPC, there's a lot of duplication between distros on the tools used to generate the initramfs as well as the contents and how the initramfs works. Ultimately, there's little reason for this not to be something that is shared and worked on by everyone. Added to this is the fact that everyone's infrastructures for this have grown up over a long-ish period of time without significant amounts of reworking for the way that the kernel and early boot works these days. Therefore I've started on a new project, dracut, to try to be a new initramfs tool that can be used across various distributions. From the README... Unlike existing initramfs's, this is an attempt at having as little as possible hard-coded into the initramfs as possible. The initramfs has (basically) one purpose in life -- getting the rootfs mounted so that we can transition to the real rootfs. This is all driven off of device availability. Therefore, instead of scripts hard-coded to do various things, we depend on udev to create device nodes for us and then when we have the rootfs's device node, we mount and carry on. This helps to keep the time required in the initramfs as little as possible so that things like a 5 second boot aren't made impossible as a result of the very existence of an initramfs. It's likely that we'll grow some hooks for running arbitrary commands in the flow of the script, but it's worth trying to resist the urge as much as we can as hooks are guaranteed to be the path to slow-down. Also, there is an attempt to keep things as distribution-agnostic as possible. Every distribution has their own tool here and it's not something which is really interesting to have separate across them. So contributions to help decrease the distro-dependencies are welcome. The git tree can be found at git://fedorapeople.org/~katzj/dracut.git for now. See the TODO file for things which still need to be done and HACKING for some instructions on how to get started using the tool. There is also a mailing list that is being used for the discussion -- initramfs@vger.kernel.org. Currently, there are a few Fedora-isms which have crept in just as a result of it being the shortest path to solving some problems, but I'm actively trying to get those out sooner rather than later as well as getting to where I'm using it to boot my laptop. Comments and discussion welcome Jeremy -- To unsubscribe from this list: send the line "unsubscribe initramfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html From initramfs-owner@vger.kernel.org Wed Dec 17 11:34:02 2008 Delivered-To: halfline@gmail.com Received: by 10.140.147.10 with SMTP id u10cs40303rvd; Wed, 17 Dec 2008 11:34:02 -0800 (PST) Received: by 10.100.126.15 with SMTP id y15mr869450anc.123.1229542442141; Wed, 17 Dec 2008 11:34:02 -0800 (PST) Return-Path: Received: from vger.kernel.org (vger.kernel.org [209.132.176.167]) by mx.google.com with ESMTP id 34si4442600yxm.4.2008.12.17.11.33.59; Wed, 17 Dec 2008 11:34:02 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of initramfs-owner@vger.kernel.org designates 209.132.176.167 as permitted sender) client-ip=209.132.176.167; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of initramfs-owner@vger.kernel.org designates 209.132.176.167 as permitted sender) smtp.mail=initramfs-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751199AbYLQTd7 (ORCPT + 4 others); Wed, 17 Dec 2008 14:33:59 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751267AbYLQTd7 (ORCPT ); Wed, 17 Dec 2008 14:33:59 -0500 Received: from charlotte.tuxdriver.com ([70.61.120.58]:50278 "EHLO smtp.tuxdriver.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751199AbYLQTd5 (ORCPT ); Wed, 17 Dec 2008 14:33:57 -0500 Received: from cpe-071-077-039-214.nc.res.rr.com ([71.77.39.214] helo=localhost) by smtp.tuxdriver.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1LD29a-0005je-6D; Wed, 17 Dec 2008 14:33:55 -0500 Date: Wed, 17 Dec 2008 14:31:51 -0500 From: Neil Horman To: initramfs@vger.kernel.org Cc: linux-kernel@vger.kernel.org, Kay Sievers , Dave Jones , cjwatson@ubuntu.com Subject: Re: Dracut -- Cross distribution initramfs infrastructure Message-ID: <20081217193151.GA7356@hmsreliant.think-freely.org> References: <1229540094.28858.150.camel@aglarond.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1229540094.28858.150.camel@aglarond.local> User-Agent: Mutt/1.5.18 (2008-05-17) X-Spam-Score: -1.4 (-) X-Spam-Status: No Sender: initramfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: initramfs@vger.kernel.org X-Evolution-Source: imap://halfline@imap.gmail.com/ Content-Transfer-Encoding: 8bit On Wed, Dec 17, 2008 at 01:54:54PM -0500, Jeremy Katz wrote: > As davej started talking about a few months ago at Kernel Summit and > LPC, there's a lot of duplication between distros on the tools used to > generate the initramfs as well as the contents and how the initramfs > works. Ultimately, there's little reason for this not to be something > that is shared and worked on by everyone. Added to this is the fact > that everyone's infrastructures for this have grown up over a long-ish > period of time without significant amounts of reworking for the way that > the kernel and early boot works these days. > > Therefore I've started on a new project, dracut, to try to be a new > initramfs tool that can be used across various distributions. From the > README... > > Unlike existing initramfs's, this is an attempt at having as little as > possible hard-coded into the initramfs as possible. The initramfs has > (basically) one purpose in life -- getting the rootfs mounted so that we > can transition to the real rootfs. This is all driven off of device > availability. Therefore, instead of scripts hard-coded to do various > things, we depend on udev to create device nodes for us and then when we > have the rootfs's device node, we mount and carry on. This helps to keep > the time required in the initramfs as little as possible so that things > like a 5 second boot aren't made impossible as a result of the very > existence of an initramfs. It's likely that we'll grow some hooks for > running arbitrary commands in the flow of the script, but it's worth > trying to resist the urge as much as we can as hooks are guaranteed to > be the path to slow-down. > > Also, there is an attempt to keep things as distribution-agnostic as > possible. Every distribution has their own tool here and it's not > something which is really interesting to have separate across them. So > contributions to help decrease the distro-dependencies are welcome. > > The git tree can be found at git://fedorapeople.org/~katzj/dracut.git > for now. See the TODO file for things which still need to be done and > HACKING for some instructions on how to get started using the tool. > There is also a mailing list that is being used for the discussion -- > initramfs@vger.kernel.org. > > Currently, there are a few Fedora-isms which have crept in just as a > result of it being the shortest path to solving some problems, but I'm > actively trying to get those out sooner rather than later as well as > getting to where I'm using it to boot my laptop. > > Comments and discussion welcome > > Jeremy > Not that I don't think a unifying tool to create an initramfs is a bad idea (quite the contrary, I think it would be great), but I'd like to point out that one of your underlying premises is a bit shaky. That an initramfs has one purpose, that being to get the rootfs mounted, isn't entirely accurate. Kdump and various embedded systems being the prime examples here. Many embedded systems run entirely out of the initramfs, and contain all the code they need to do so in them. Additionally, kdump in most environments, attemps to capture core files entirely from the initramfs as well, operating under the assumption that the rootfs may not be functioning properly after a crash. By and large these initramfs images tend to be larger and offer a more typical (if not standard) user operating environment. I'm looking at your tree now, and it looks like a good start on standardizing the initramfs for the nominal case. Do you have plans to include (or are you interested in including) support for alternate infrastructure (like busybox instead of nash), interactive setup, etc? Regards Neil -- /**************************************************** * Neil Horman * Software Engineer, Red Hat ****************************************************/ -- To unsubscribe from this list: send the line "unsubscribe initramfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html From initramfs-owner@vger.kernel.org Wed Dec 17 11:51:38 2008 Delivered-To: halfline@gmail.com Received: by 10.140.147.10 with SMTP id u10cs41146rvd; Wed, 17 Dec 2008 11:51:38 -0800 (PST) Received: by 10.90.100.20 with SMTP id x20mr687708agb.47.1229543497550; Wed, 17 Dec 2008 11:51:37 -0800 (PST) Return-Path: Received: from vger.kernel.org (vger.kernel.org [209.132.176.167]) by mx.google.com with ESMTP id 33si8122038yxr.32.2008.12.17.11.51.34; Wed, 17 Dec 2008 11:51:37 -0800 (PST) Received-SPF: pass (google.com: domain of initramfs-owner@vger.kernel.org designates 209.132.176.167 as permitted sender) client-ip=209.132.176.167; Authentication-Results: mx.google.com; spf=pass (google.com: domain of initramfs-owner@vger.kernel.org designates 209.132.176.167 as permitted sender) smtp.mail=initramfs-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751288AbYLQTvI (ORCPT + 4 others); Wed, 17 Dec 2008 14:51:08 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751224AbYLQTvI (ORCPT ); Wed, 17 Dec 2008 14:51:08 -0500 Received: from mx2.redhat.com ([66.187.237.31]:57236 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751288AbYLQTvH (ORCPT ); Wed, 17 Dec 2008 14:51:07 -0500 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id mBHJoxw8032177; Wed, 17 Dec 2008 14:50:59 -0500 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id mBHJowvl005286; Wed, 17 Dec 2008 14:50:58 -0500 Received: from [10.11.13.109] (vpn-13-109.rdu.redhat.com [10.11.13.109]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id mBHJovUF026554; Wed, 17 Dec 2008 14:50:57 -0500 Subject: Re: Dracut -- Cross distribution initramfs infrastructure From: Jeremy Katz To: Neil Horman Cc: initramfs@vger.kernel.org, Kay Sievers , cjwatson@ubuntu.com In-Reply-To: <20081217193151.GA7356@hmsreliant.think-freely.org> References: <1229540094.28858.150.camel@aglarond.local> <20081217193151.GA7356@hmsreliant.think-freely.org> Content-Type: text/plain Date: Wed, 17 Dec 2008 14:48:29 -0500 Message-Id: <1229543309.28858.163.camel@aglarond.local> Mime-Version: 1.0 X-Scanned-By: MIMEDefang 2.58 on 172.16.27.26 Sender: initramfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: initramfs@vger.kernel.org X-Evolution-Source: imap://halfline@imap.gmail.com/ Content-Transfer-Encoding: 8bit (Removing lkml from the cc) On Wed, 2008-12-17 at 14:31 -0500, Neil Horman wrote: > Not that I don't think a unifying tool to create an initramfs is a bad idea > (quite the contrary, I think it would be great), but I'd like to point out that > one of your underlying premises is a bit shaky. That an initramfs has one > purpose, that being to get the rootfs mounted, isn't entirely accurate. Kdump > and various embedded systems being the prime examples here. Many embedded > systems run entirely out of the initramfs, and contain all the code they need to > do so in them. Additionally, kdump in most environments, attemps to capture > core files entirely from the initramfs as well, operating under the assumption > that the rootfs may not be functioning properly after a crash. By and large > these initramfs images tend to be larger and offer a more typical (if not > standard) user operating environment. While I'd like to think that embedded systems are not going to do something custom, you, I and everyone else know that's unlikely. ;-) The kdump case is one that I think is at least reasonable to get to eventually (and also, installer initramfsen), but I think that getting the cases of "initramfs for booting a system" consolidated first makes the most sense. > I'm looking at your tree now, and it > looks like a good start on standardizing the initramfs for the nominal case. Do > you have plans to include (or are you interested in including) support for > alternate infrastructure (like busybox instead of nash), interactive setup, etc? Well, the use of nash right now is due to the fact that there isn't historically any switchroot utility shipped in util-linux. Hopefully we'll get something there and then the only user of nash that's there right now can go away. busybox, etc are really all just extra pain as compared to using real system utilities... once you accept that you're dynamically linked, you're better off just maintaining one set of the utilities as opposed to having one set in coreutils and one set in busybox. Jeremy -- To unsubscribe from this list: send the line "unsubscribe initramfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html From initramfs-owner@vger.kernel.org Wed Dec 17 12:20:01 2008 Delivered-To: halfline@gmail.com Received: by 10.140.147.10 with SMTP id u10cs42293rvd; Wed, 17 Dec 2008 12:20:01 -0800 (PST) Received: by 10.214.243.13 with SMTP id q13mr1497066qah.34.1229545200921; Wed, 17 Dec 2008 12:20:00 -0800 (PST) Return-Path: Received: from vger.kernel.org (vger.kernel.org [209.132.176.167]) by mx.google.com with ESMTP id 9si3797124yxs.15.2008.12.17.12.19.58; Wed, 17 Dec 2008 12:20:00 -0800 (PST) Received-SPF: pass (google.com: domain of initramfs-owner@vger.kernel.org designates 209.132.176.167 as permitted sender) client-ip=209.132.176.167; Authentication-Results: mx.google.com; spf=pass (google.com: domain of initramfs-owner@vger.kernel.org designates 209.132.176.167 as permitted sender) smtp.mail=initramfs-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751047AbYLQUTz (ORCPT + 4 others); Wed, 17 Dec 2008 15:19:55 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751169AbYLQUTz (ORCPT ); Wed, 17 Dec 2008 15:19:55 -0500 Received: from charlotte.tuxdriver.com ([70.61.120.58]:54093 "EHLO smtp.tuxdriver.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751047AbYLQUTy (ORCPT ); Wed, 17 Dec 2008 15:19:54 -0500 Received: from cpe-071-077-039-214.nc.res.rr.com ([71.77.39.214] helo=localhost) by smtp.tuxdriver.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1LD2s2-00061p-NM; Wed, 17 Dec 2008 15:19:51 -0500 Date: Wed, 17 Dec 2008 15:17:43 -0500 From: Neil Horman To: Jeremy Katz , t@hmsreliant.think-freely.org Cc: initramfs@vger.kernel.org, Kay Sievers , cjwatson@ubuntu.com Subject: Re: Dracut -- Cross distribution initramfs infrastructure Message-ID: <20081217201743.GB7356@hmsreliant.think-freely.org> References: <1229540094.28858.150.camel@aglarond.local> <20081217193151.GA7356@hmsreliant.think-freely.org> <1229543309.28858.163.camel@aglarond.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1229543309.28858.163.camel@aglarond.local> User-Agent: Mutt/1.5.18 (2008-05-17) X-Spam-Score: -1.4 (-) X-Spam-Status: No Sender: initramfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: initramfs@vger.kernel.org X-Evolution-Source: imap://halfline@imap.gmail.com/ Content-Transfer-Encoding: 8bit On Wed, Dec 17, 2008 at 02:48:29PM -0500, Jeremy Katz wrote: > (Removing lkml from the cc) > > On Wed, 2008-12-17 at 14:31 -0500, Neil Horman wrote: > > Not that I don't think a unifying tool to create an initramfs is a bad idea > > (quite the contrary, I think it would be great), but I'd like to point out that > > one of your underlying premises is a bit shaky. That an initramfs has one > > purpose, that being to get the rootfs mounted, isn't entirely accurate. Kdump > > and various embedded systems being the prime examples here. Many embedded > > systems run entirely out of the initramfs, and contain all the code they need to > > do so in them. Additionally, kdump in most environments, attemps to capture > > core files entirely from the initramfs as well, operating under the assumption > > that the rootfs may not be functioning properly after a crash. By and large > > these initramfs images tend to be larger and offer a more typical (if not > > standard) user operating environment. > > While I'd like to think that embedded systems are not going to do > something custom, you, I and everyone else know that's unlikely. ;-) > Agreed :) > The kdump case is one that I think is at least reasonable to get to > eventually (and also, installer initramfsen), but I think that getting > the cases of "initramfs for booting a system" consolidated first makes > the most sense. > Absolutely, thats fine with me. I just didn't want everyone to assume that getting to the rootfs was the only thing that initramfs' did. Adding kdump support later is well and good. > > I'm looking at your tree now, and it > > looks like a good start on standardizing the initramfs for the nominal case. Do > > you have plans to include (or are you interested in including) support for > > alternate infrastructure (like busybox instead of nash), interactive setup, etc? > > Well, the use of nash right now is due to the fact that there isn't > historically any switchroot utility shipped in util-linux. Hopefully > we'll get something there and then the only user of nash that's there > right now can go away. > Thats true, and a small part of the reason that most kdump implementations use busybox. > busybox, etc are really all just extra pain as compared to using real > system utilities... once you accept that you're dynamically linked, > you're better off just maintaining one set of the utilities as opposed > to having one set in coreutils and one set in busybox. > I'm not so sure I agree with that, but I'll not turn this thread into that argument :). Suffice it to say, That if we can cram ifconfig, sed, awk, lsmod, modprobe, bash, cp, grep, reboot, halt, ps, kill, and pivot_root and a few other utils into less than 1.8MB of space, switching might be worthwhile. Neil > Jeremy > > -- /**************************************************** * Neil Horman * Software Engineer, Red Hat ****************************************************/ -- To unsubscribe from this list: send the line "unsubscribe initramfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html From initramfs-owner@vger.kernel.org Wed Dec 17 12:30:12 2008 Delivered-To: halfline@gmail.com Received: by 10.140.147.10 with SMTP id u10cs42748rvd; Wed, 17 Dec 2008 12:30:12 -0800 (PST) Received: by 10.214.59.13 with SMTP id h13mr1468027qaa.296.1229545811279; Wed, 17 Dec 2008 12:30:11 -0800 (PST) Return-Path: Received: from vger.kernel.org (vger.kernel.org [209.132.176.167]) by mx.google.com with ESMTP id 30si4771055yxk.27.2008.12.17.12.30.08; Wed, 17 Dec 2008 12:30:11 -0800 (PST) Received-SPF: pass (google.com: domain of initramfs-owner@vger.kernel.org designates 209.132.176.167 as permitted sender) client-ip=209.132.176.167; Authentication-Results: mx.google.com; spf=pass (google.com: domain of initramfs-owner@vger.kernel.org designates 209.132.176.167 as permitted sender) smtp.mail=initramfs-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751279AbYLQU3y (ORCPT + 4 others); Wed, 17 Dec 2008 15:29:54 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751297AbYLQU3x (ORCPT ); Wed, 17 Dec 2008 15:29:53 -0500 Received: from mail-ew0-f17.google.com ([209.85.219.17]:54835 "EHLO mail-ew0-f17.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751279AbYLQU3x (ORCPT ); Wed, 17 Dec 2008 15:29:53 -0500 Received: by ewy10 with SMTP id 10so103486ewy.13 for ; Wed, 17 Dec 2008 12:29:51 -0800 (PST) Received: by 10.210.67.4 with SMTP id p4mr1312356eba.165.1229545791196; Wed, 17 Dec 2008 12:29:51 -0800 (PST) Received: by 10.210.81.4 with HTTP; Wed, 17 Dec 2008 12:29:51 -0800 (PST) Message-ID: Date: Wed, 17 Dec 2008 21:29:51 +0100 From: "Kay Sievers" To: "Jeremy Katz" Subject: Re: Dracut -- Cross distribution initramfs infrastructure Cc: "Neil Horman" , initramfs@vger.kernel.org, cjwatson@ubuntu.com, "Karel Zak" In-Reply-To: <1229543309.28858.163.camel@aglarond.local> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Disposition: inline References: <1229540094.28858.150.camel@aglarond.local> <20081217193151.GA7356@hmsreliant.think-freely.org> <1229543309.28858.163.camel@aglarond.local> Sender: initramfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: initramfs@vger.kernel.org X-Evolution-Source: imap://halfline@imap.gmail.com/ Content-Transfer-Encoding: 8bit On Wed, Dec 17, 2008 at 20:48, Jeremy Katz wrote: > On Wed, 2008-12-17 at 14:31 -0500, Neil Horman wrote: >> Not that I don't think a unifying tool to create an initramfs is a bad idea >> (quite the contrary, I think it would be great), but I'd like to point out that >> one of your underlying premises is a bit shaky. That an initramfs has one >> purpose, that being to get the rootfs mounted, isn't entirely accurate. Kdump >> and various embedded systems being the prime examples here. Many embedded >> systems run entirely out of the initramfs, and contain all the code they need to >> do so in them. Additionally, kdump in most environments, attemps to capture >> core files entirely from the initramfs as well, operating under the assumption >> that the rootfs may not be functioning properly after a crash. By and large >> these initramfs images tend to be larger and offer a more typical (if not >> standard) user operating environment. > > While I'd like to think that embedded systems are not going to do > something custom, you, I and everyone else know that's unlikely. ;-) > > The kdump case is one that I think is at least reasonable to get to > eventually (and also, installer initramfsen), but I think that getting > the cases of "initramfs for booting a system" consolidated first makes > the most sense. Maybe Bernhard Walle, who currently maintains the SUSE initramfs, can possibly take care of that. He's is working on kdump stuff. >> I'm looking at your tree now, and it >> looks like a good start on standardizing the initramfs for the nominal case. Do >> you have plans to include (or are you interested in including) support for >> alternate infrastructure (like busybox instead of nash), interactive setup, etc? > > Well, the use of nash right now is due to the fact that there isn't > historically any switchroot utility shipped in util-linux. Hopefully > we'll get something there and then the only user of nash that's there > right now can go away. SUSE uses a small binary run-init copied from klibc: http://git.kernel.org/?p=libs/klibc/klibc.git;a=blob;f=usr/kinit/run-init/run-init.c;hb=HEAD Maybe it's time to add something like that to util-linux? Karel? > busybox, etc are really all just extra pain as compared to using real > system utilities... once you accept that you're dynamically linked, > you're better off just maintaining one set of the utilities as opposed > to having one set in coreutils and one set in busybox. Busybox is nice as an option to be able to rescue/hack. It should definitely be provided as an optional "plugin" for people who need it. But there is no chance to depend on it by default, for the very same reason klibc, or any other libc is not an option. Full-featured distros who make their money with support, can just not afford to support tools compiled differently from the tools in the real rootfs. SUSE used klibc for one release, and stopped doing that immediately, because you go crazy if you run into problems with bootup problems on cutomer setups you can not reproduce with the tools from the real rootfs. We need to use tools in initramfs which will not work realibly, or not at all, with other libcs. We will have one dynamic glibc there anyway, so there is no valid reason to also use any single statically linked binary, or any other libc by default. Really, it's just nice to use the same environment in the real root and in initramfs, and you also get the smallest possible size that way, if you need to include only a single "advanced" tool. Thanks, Kay -- To unsubscribe from this list: send the line "unsubscribe initramfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html From initramfs-owner@vger.kernel.org Wed Dec 17 13:08:57 2008 Delivered-To: halfline@gmail.com Received: by 10.140.147.10 with SMTP id u10cs44529rvd; Wed, 17 Dec 2008 13:08:57 -0800 (PST) Received: by 10.215.67.14 with SMTP id u14mr1518334qak.381.1229548137286; Wed, 17 Dec 2008 13:08:57 -0800 (PST) Return-Path: Received: from vger.kernel.org (vger.kernel.org [209.132.176.167]) by mx.google.com with ESMTP id 34si4764734yxm.14.2008.12.17.13.08.54; Wed, 17 Dec 2008 13:08:57 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of initramfs-owner@vger.kernel.org designates 209.132.176.167 as permitted sender) client-ip=209.132.176.167; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of initramfs-owner@vger.kernel.org designates 209.132.176.167 as permitted sender) smtp.mail=initramfs-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751214AbYLQVIx (ORCPT + 4 others); Wed, 17 Dec 2008 16:08:53 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751226AbYLQVIx (ORCPT ); Wed, 17 Dec 2008 16:08:53 -0500 Received: from charlotte.tuxdriver.com ([70.61.120.58]:57638 "EHLO smtp.tuxdriver.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751214AbYLQVIw (ORCPT ); Wed, 17 Dec 2008 16:08:52 -0500 Received: from cpe-071-077-039-214.nc.res.rr.com ([71.77.39.214] helo=localhost) by smtp.tuxdriver.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1LD3dQ-0006Ga-9c; Wed, 17 Dec 2008 16:08:49 -0500 Date: Wed, 17 Dec 2008 16:06:45 -0500 From: Neil Horman To: Kay Sievers Cc: Jeremy Katz , initramfs@vger.kernel.org, cjwatson@ubuntu.com, Karel Zak Subject: Re: Dracut -- Cross distribution initramfs infrastructure Message-ID: <20081217210645.GC7356@hmsreliant.think-freely.org> References: <1229540094.28858.150.camel@aglarond.local> <20081217193151.GA7356@hmsreliant.think-freely.org> <1229543309.28858.163.camel@aglarond.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) X-Spam-Score: -1.4 (-) X-Spam-Status: No Sender: initramfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: initramfs@vger.kernel.org X-Evolution-Source: imap://halfline@imap.gmail.com/ Content-Transfer-Encoding: 8bit On Wed, Dec 17, 2008 at 09:29:51PM +0100, Kay Sievers wrote: > On Wed, Dec 17, 2008 at 20:48, Jeremy Katz wrote: > > On Wed, 2008-12-17 at 14:31 -0500, Neil Horman wrote: > >> Not that I don't think a unifying tool to create an initramfs is a bad idea > >> (quite the contrary, I think it would be great), but I'd like to point out that > >> one of your underlying premises is a bit shaky. That an initramfs has one > >> purpose, that being to get the rootfs mounted, isn't entirely accurate. Kdump > >> and various embedded systems being the prime examples here. Many embedded > >> systems run entirely out of the initramfs, and contain all the code they need to > >> do so in them. Additionally, kdump in most environments, attemps to capture > >> core files entirely from the initramfs as well, operating under the assumption > >> that the rootfs may not be functioning properly after a crash. By and large > >> these initramfs images tend to be larger and offer a more typical (if not > >> standard) user operating environment. > > > > While I'd like to think that embedded systems are not going to do > > something custom, you, I and everyone else know that's unlikely. ;-) > > > > The kdump case is one that I think is at least reasonable to get to > > eventually (and also, installer initramfsen), but I think that getting > > the cases of "initramfs for booting a system" consolidated first makes > > the most sense. > > Maybe Bernhard Walle, who currently maintains the SUSE initramfs, can > possibly take care of that. He's is working on kdump stuff. > I do to, thats why I brought it up :) > >> I'm looking at your tree now, and it > >> looks like a good start on standardizing the initramfs for the nominal case. Do > >> you have plans to include (or are you interested in including) support for > >> alternate infrastructure (like busybox instead of nash), interactive setup, etc? > > > > Well, the use of nash right now is due to the fact that there isn't > > historically any switchroot utility shipped in util-linux. Hopefully > > we'll get something there and then the only user of nash that's there > > right now can go away. > > SUSE uses a small binary run-init copied from klibc: > http://git.kernel.org/?p=libs/klibc/klibc.git;a=blob;f=usr/kinit/run-init/run-init.c;hb=HEAD > Maybe it's time to add something like that to util-linux? Karel? > > > busybox, etc are really all just extra pain as compared to using real > > system utilities... once you accept that you're dynamically linked, > > you're better off just maintaining one set of the utilities as opposed > > to having one set in coreutils and one set in busybox. > > Busybox is nice as an option to be able to rescue/hack. It should > definitely be provided as an optional "plugin" for people who need it. > But there is no chance to depend on it by default, for the very same > reason klibc, or any other libc is not an option. > > Full-featured distros who make their money with support, can just not > afford to support tools compiled differently from the tools in the > real rootfs. SUSE used klibc for one release, and stopped doing that > immediately, because you go crazy if you run into problems with bootup > problems on cutomer setups you can not reproduce with the tools from > the real rootfs. > This is all hyperbolie. Yes, its nice to be able to use the same tools and the same environment, but busybox works perfectly well in a kdump environment. I've used busybox in Fedora and RHEL, and since RHEL5 and FC-6 shipped, I've encounted I think 3 bugs that dealt with minor differences in how busybox worked from the rootfs tools > We need to use tools in initramfs which will not work realibly, or not > at all, with other libcs. We will have one dynamic glibc there anyway, > so there is no valid reason to also use any single statically linked > binary, or any other libc by default. Really, it's just nice to use > the same environment in the real root and in initramfs, and you also > get the smallest possible size that way, if you need to include only a > single "advanced" tool. > busybox is dynamically linked now too, so C library issues are irrelevant at this point. And busybox provides, at my last count 255 utilities in the Fedora build. Compare that to the cumulative size of all the corresponding individual utilities and see who comes out taking up less space. Neil > Thanks, > Kay > -- /**************************************************** * Neil Horman * Software Engineer, Red Hat ****************************************************/ -- To unsubscribe from this list: send the line "unsubscribe initramfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html From initramfs-owner@vger.kernel.org Wed Dec 17 13:16:54 2008 Delivered-To: halfline@gmail.com Received: by 10.140.147.10 with SMTP id u10cs44835rvd; Wed, 17 Dec 2008 13:16:54 -0800 (PST) Received: by 10.214.44.14 with SMTP id r14mr1559140qar.219.1229548613314; Wed, 17 Dec 2008 13:16:53 -0800 (PST) Return-Path: Received: from vger.kernel.org (vger.kernel.org [209.132.176.167]) by mx.google.com with ESMTP id 4si5501532yxd.20.2008.12.17.13.16.50; Wed, 17 Dec 2008 13:16:53 -0800 (PST) Received-SPF: pass (google.com: domain of initramfs-owner@vger.kernel.org designates 209.132.176.167 as permitted sender) client-ip=209.132.176.167; Authentication-Results: mx.google.com; spf=pass (google.com: domain of initramfs-owner@vger.kernel.org designates 209.132.176.167 as permitted sender) smtp.mail=initramfs-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751237AbYLQVQq (ORCPT + 4 others); Wed, 17 Dec 2008 16:16:46 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751248AbYLQVQq (ORCPT ); Wed, 17 Dec 2008 16:16:46 -0500 Received: from mx2.redhat.com ([66.187.237.31]:56599 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751237AbYLQVQp (ORCPT ); Wed, 17 Dec 2008 16:16:45 -0500 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id mBHLGfxR015472; Wed, 17 Dec 2008 16:16:41 -0500 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id mBHLGeh9031096; Wed, 17 Dec 2008 16:16:40 -0500 Received: from [10.16.10.154] (vpn-10-154.bos.redhat.com [10.16.10.154]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id mBHLGdrv007180; Wed, 17 Dec 2008 16:16:39 -0500 Subject: Re: Dracut -- Cross distribution initramfs infrastructure From: David Zeuthen To: Neil Horman Cc: Kay Sievers , Jeremy Katz , initramfs@vger.kernel.org, cjwatson@ubuntu.com, Karel Zak In-Reply-To: <20081217210645.GC7356@hmsreliant.think-freely.org> References: <1229540094.28858.150.camel@aglarond.local> <20081217193151.GA7356@hmsreliant.think-freely.org> <1229543309.28858.163.camel@aglarond.local> <20081217210645.GC7356@hmsreliant.think-freely.org> Content-Type: text/plain Organization: Red Hat, Inc. Date: Wed, 17 Dec 2008 16:15:07 -0500 Message-Id: <1229548507.1229.4.camel@x61.fubar.dk> Mime-Version: 1.0 X-Scanned-By: MIMEDefang 2.58 on 172.16.27.26 Sender: initramfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: initramfs@vger.kernel.org X-Evolution-Source: imap://halfline@imap.gmail.com/ Content-Transfer-Encoding: 8bit On Wed, 2008-12-17 at 16:06 -0500, Neil Horman wrote: > > Busybox is nice as an option to be able to rescue/hack. It should > > definitely be provided as an optional "plugin" for people who need it. > > But there is no chance to depend on it by default, for the very same > > reason klibc, or any other libc is not an option. > > > > Full-featured distros who make their money with support, can just not > > afford to support tools compiled differently from the tools in the > > real rootfs. SUSE used klibc for one release, and stopped doing that > > immediately, because you go crazy if you run into problems with bootup > > problems on cutomer setups you can not reproduce with the tools from > > the real rootfs. > > > This is all hyperbolie. Hardly. Having to support two different C libraries in a real production environment, for reasons like "just because we can" and "it's about freedom" is not something I ever want this project to see or support. In there lies madness. FWIW, as Kay said, it's fine to have an unsupported "--with-busybox" or whatever option but please don't think that people using it can expect any kind of real support or attention to their bug reports. David -- To unsubscribe from this list: send the line "unsubscribe initramfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html From initramfs-owner@vger.kernel.org Wed Dec 17 13:25:24 2008 Delivered-To: halfline@gmail.com Received: by 10.140.147.10 with SMTP id u10cs45135rvd; Wed, 17 Dec 2008 13:25:24 -0800 (PST) Received: by 10.215.66.1 with SMTP id t1mr1556797qak.327.1229549123617; Wed, 17 Dec 2008 13:25:23 -0800 (PST) Return-Path: Received: from vger.kernel.org (vger.kernel.org [209.132.176.167]) by mx.google.com with ESMTP id 6si6122962yxg.33.2008.12.17.13.25.20; Wed, 17 Dec 2008 13:25:23 -0800 (PST) Received-SPF: pass (google.com: domain of initramfs-owner@vger.kernel.org designates 209.132.176.167 as permitted sender) client-ip=209.132.176.167; Authentication-Results: mx.google.com; spf=pass (google.com: domain of initramfs-owner@vger.kernel.org designates 209.132.176.167 as permitted sender) smtp.mail=initramfs-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752750AbYLQVY6 (ORCPT + 4 others); Wed, 17 Dec 2008 16:24:58 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751906AbYLQVY6 (ORCPT ); Wed, 17 Dec 2008 16:24:58 -0500 Received: from charlotte.tuxdriver.com ([70.61.120.58]:40637 "EHLO smtp.tuxdriver.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752434AbYLQVY5 (ORCPT ); Wed, 17 Dec 2008 16:24:57 -0500 Received: from cpe-071-077-039-214.nc.res.rr.com ([71.77.39.214] helo=localhost) by smtp.tuxdriver.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1LD3sy-0006MS-Oa; Wed, 17 Dec 2008 16:24:53 -0500 Date: Wed, 17 Dec 2008 16:22:50 -0500 From: Neil Horman To: David Zeuthen Cc: Kay Sievers , Jeremy Katz , initramfs@vger.kernel.org, cjwatson@ubuntu.com, Karel Zak Subject: Re: Dracut -- Cross distribution initramfs infrastructure Message-ID: <20081217212250.GE7356@hmsreliant.think-freely.org> References: <1229540094.28858.150.camel@aglarond.local> <20081217193151.GA7356@hmsreliant.think-freely.org> <1229543309.28858.163.camel@aglarond.local> <20081217210645.GC7356@hmsreliant.think-freely.org> <1229548507.1229.4.camel@x61.fubar.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1229548507.1229.4.camel@x61.fubar.dk> User-Agent: Mutt/1.5.18 (2008-05-17) X-Spam-Score: -1.4 (-) X-Spam-Status: No Sender: initramfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: initramfs@vger.kernel.org X-Evolution-Source: imap://halfline@imap.gmail.com/ Content-Transfer-Encoding: 8bit On Wed, Dec 17, 2008 at 04:15:07PM -0500, David Zeuthen wrote: > On Wed, 2008-12-17 at 16:06 -0500, Neil Horman wrote: > > > Busybox is nice as an option to be able to rescue/hack. It should > > > definitely be provided as an optional "plugin" for people who need it. > > > But there is no chance to depend on it by default, for the very same > > > reason klibc, or any other libc is not an option. > > > > > > Full-featured distros who make their money with support, can just not > > > afford to support tools compiled differently from the tools in the > > > real rootfs. SUSE used klibc for one release, and stopped doing that > > > immediately, because you go crazy if you run into problems with bootup > > > problems on cutomer setups you can not reproduce with the tools from > > > the real rootfs. > > > > > This is all hyperbolie. > > Hardly. Having to support two different C libraries in a real production > environment, for reasons like "just because we can" and "it's about > freedom" is not something I ever want this project to see or support. In > there lies madness. > Either I wasn't clear, or you didn't read closely enough. I don't use two different c libraries, We use the same C library everywhere, busybox included. Which is not to say you have to do that. You can certainly use a different library, and I agree with you there, to use two different C libraries in the same system is rather insane. But I don't do that, and unless you are _that_ constrained for space, you don't need to. > FWIW, as Kay said, it's fine to have an unsupported "--with-busybox" or > whatever option but please don't think that people using it can expect > any kind of real support or attention to their bug reports. > Seea above. > David > > > -- /**************************************************** * Neil Horman * Software Engineer, Red Hat ****************************************************/ -- To unsubscribe from this list: send the line "unsubscribe initramfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html