Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932564AbVKAHwp (ORCPT ); Tue, 1 Nov 2005 02:52:45 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S932567AbVKAHwo (ORCPT ); Tue, 1 Nov 2005 02:52:44 -0500 Received: from caramon.arm.linux.org.uk ([212.18.232.186]:54540 "EHLO caramon.arm.linux.org.uk") by vger.kernel.org with ESMTP id S932564AbVKAHwo (ORCPT ); Tue, 1 Nov 2005 02:52:44 -0500 Date: Tue, 1 Nov 2005 07:52:29 +0000 From: Russell King To: Linus Torvalds Cc: Andrew Morton , Roman Zippel , ak@suse.de, tony.luck@gmail.com, paolo.ciarrocchi@gmail.com, linux-kernel@vger.kernel.org Subject: Re: New (now current development process) Message-ID: <20051101075229.GB22053@flint.arm.linux.org.uk> Mail-Followup-To: Linus Torvalds , Andrew Morton , Roman Zippel , ak@suse.de, tony.luck@gmail.com, paolo.ciarrocchi@gmail.com, linux-kernel@vger.kernel.org References: <4d8e3fd30510291026x611aa715pc1a153e706e70bc2@mail.gmail.com> <20051031001647.GK2846@flint.arm.linux.org.uk> <20051030172247.743d77fa.akpm@osdl.org> <200510310341.02897.ak@suse.de> <20051031160557.7540cd6a.akpm@osdl.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1542 Lines: 36 On Mon, Oct 31, 2005 at 04:13:22PM -0800, Linus Torvalds wrote: > On Mon, 31 Oct 2005, Andrew Morton wrote: > > Are you sure these kernels are feature-equivalent? > > They may not be feature-equivalent in reality, but it's hard to generate > something that has the features (or lack there-of) of old kernels these > days. Which is problematic. > > But some of it is likely also compilers. gcc does insane padding in many > cases these days. > > And a lot of it is us just being bloated. Argh. Which is one of the reasons I've started working on fixing up the platform device/driver stuff to conform to the "usual" method, with the view to killing off _all_ the function pointers in struct device_driver. Most bus types wrap struct device_driver, and then provide their own function pointers which pass their bus-type specific device structure. This does two things: 1. it centralises the conversion from struct device to struct whatever_device, and 2. improves typechecking. However, once the use of the function pointers in struct device_driver have been eliminated, we can be sure of reclaiming at least 20 bytes per device driver, maybe more if GCC does insane padding. -- Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 Serial core - 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/