Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Tue, 28 Nov 2000 19:24:38 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Tue, 28 Nov 2000 19:24:28 -0500 Received: from wire.cadcamlab.org ([156.26.20.181]:49927 "EHLO wire.cadcamlab.org") by vger.kernel.org with ESMTP id ; Tue, 28 Nov 2000 19:24:20 -0500 Date: Tue, 28 Nov 2000 17:53:48 -0600 To: Tigran Aivazian Cc: David Hinds , linux-kernel@vger.kernel.org Subject: Re: [PATCH] removal of "static foo = 0" from drivers/ide (test11) Message-ID: <20001128175348.J8881@wire.cadcamlab.org> In-Reply-To: <20001128125840.A28888@valinux.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from tigran@veritas.com on Tue, Nov 28, 2000 at 09:08:13PM +0000 From: Peter Samuelson Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org [Tigran Aivazian] > First, they are not trivially equivalent. In fact, they are not > equivalent at all. Any good C book should tell you that one places > data in "data segment" and another in "bss segment" (with a footnote > explaining historical meaning of "block started by symbol") Do you have an ISO C standard to refer to? I don't, but my guess is that the standard does not even *mention* discreet data sections. It *does* say that globals and statics are implicitly initialized to 0 -- the rest is a mere implementation issue. So yes, the two statements *are* trivially equivalent, unless I'm wrong and the standard *does* talk about data sections. > For example a programmer could expect the variable to be in .data for > binary patching the object Binary patching? If you are binary patching something you need to get the exact location, one way or another. Whatever tool you use to extract the location of a symbol in an object file, that same tool should tell you which section it is in. If the tool only looks in '.data', it is flawed. [David Hinds] > > Did the savings really work out to be measured in kb's of space? I > > would have expected compression to eliminate most of the savings. Some boot targets are not compressed. And the variables are scattered through the .data section rather than all in one place, so the 0s may not compress as well as you'd think. Anyway, by some estimates 'vmlinux' has gone down by several kilobytes due to these patches. Obviously the exact savings depend on .config . Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/