Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751177AbWHBE7j (ORCPT ); Wed, 2 Aug 2006 00:59:39 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751184AbWHBE7j (ORCPT ); Wed, 2 Aug 2006 00:59:39 -0400 Received: from ebiederm.dsl.xmission.com ([166.70.28.69]:4042 "EHLO ebiederm.dsl.xmission.com") by vger.kernel.org with ESMTP id S1751177AbWHBE7g (ORCPT ); Wed, 2 Aug 2006 00:59:36 -0400 From: ebiederm@xmission.com (Eric W. Biederman) To: Andi Kleen Cc: linux-kernel@vger.kernel.org, Horms , Jan Kratochvil , "H. Peter Anvin" , Magnus Damm , Vivek Goyal , Linda Wang Subject: Re: [PATCH 9/33] i386 boot: Add serial output support to the decompressor References: <200608020507.50590.ak@suse.de> Date: Tue, 01 Aug 2006 22:57:54 -0600 In-Reply-To: <200608020507.50590.ak@suse.de> (Andi Kleen's message of "Wed, 2 Aug 2006 05:07:50 +0200") Message-ID: User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/21.4 (gnu/linux) 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 Content-Length: 1493 Lines: 41 Andi Kleen writes: >> > Actually the best way to reuse would be to first do 64bit uncompressor >> > and linker directly, but short of that #includes would be fine too. >> >> > Would be better to just pull in lib/string.c >> >> Maybe. Size is fairly important > > Why is size important here? For the same reason that we compress the kernel. ;) This is the one chunk of code that we don't compress so every extra byte makes our executable bigger. Now I think the code size is actually in the 32k - 64k range so as long as it is a minor change it doesn't really matter. The big pain with using lib/string.c and arch/x86_64/kernel/early_printk.c is that it is significant change in how the code of misc.c is constructed. Which means some serious reevaluation of all kinds of things need to be considered. Making it a lot of work :) One of the practical dangers is that we make it more likely we can kill the boot by messing up the shared code. I'm not certain what to think when even including normal kernel headers causes problems. It certainly makes me leery of including normal kernel code. But it might simplify some of the problems too. Whichever way I go scrutinizing that possibility carefully is a lot of work. Eric - 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/