Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Sat, 8 Mar 2003 15:58:16 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Sat, 8 Mar 2003 15:58:16 -0500 Received: from terminus.zytor.com ([63.209.29.3]:30643 "EHLO terminus.zytor.com") by vger.kernel.org with ESMTP id ; Sat, 8 Mar 2003 15:58:15 -0500 Message-ID: <3E6A5BC2.6040808@zytor.com> Date: Sat, 08 Mar 2003 13:08:18 -0800 From: "H. Peter Anvin" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/20030211 X-Accept-Language: en-us, en, sv MIME-Version: 1.0 To: "Eric W. Biederman" CC: Russell King , Linus Torvalds , Roman Zippel , Greg KH , linux-kernel@vger.kernel.org Subject: Re: [BK PATCH] klibc for 2.5.64 - try 2 References:

<20030307233916.Q17492@flint.arm.linux.org.uk> <20030308100359.A27153@flint.arm.linux.org.uk> <20030308161309.B1896@flint.arm.linux.org.uk> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1871 Lines: 43 Eric W. Biederman wrote: > > I don't recall anything about the contents of initramfs being specified. > What I was expecting to see was a good set of general purpose policies > being included in the default kernel binary. And just replacing > /sbin/kinit if I wanted something dramatically different. And that is > what I remember Al Viro working on. > > So I don't think building a very specific /sbin/kinit that > only does what the kernel currently does right now is a problem. > It does matter how the initramfs is built. /bin/sh may or may not be necessary (but klibc /bin/sh is just over 50K on i386 -- 55K static, whereas glibcx /bin/bash is 600K plus the glibc binary), but one of the goals with initramfs is to at least make it feasible to give someone who comes and asks "I have a weird-ass site with 20000 hosts and we need X" a better answer then "well, go hack the kernel." /sbin/kinit is a feasible way to do it, but it's important to keep the flexibility option open. > So I think we should have a very small very specific /sbin/kinit > that does in user space what the kernel does in kernel space right > now. Regardless of klibc the default /sbin/kinit should be gpl'd > because we are moving code from code from the kernel into it, and we > shouldn't need to double check the licenses to move code from the > kernel into it. Agreed (although it's harder than you think to move code from the kernel into it -- frequently it has been easier to just write code from scratch; it's cleaner that way, too.) The reason I wanted to use BSD/MIT license only really applies to the library. -hpa - 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/