Message-ID: <43204609.60203@xfs.org>
Date: Thu, 08 Sep 2005 09:09:13 -0500
From: Steve Lord <lord@xfs.org>
User-Agent: Mozilla Thunderbird 1.0.6-1.1.fc4 (X11/20050720)
MIME-Version: 1.0
To: Christoph Hellwig <hch@infradead.org>
CC: Craig Rodrigues <rodrigc@crodrigues.org>, linux-xfs@oss.sgi.com
Subject: Re: Warnings when compiling xfs_macros.c
References: <20050907174535.GA1850@crodrigues.org> <20050907182059.GA13074@infradead.org> <20050907184542.GA2316@crodrigues.org> <20050908105745.GA5847@infradead.org>
In-Reply-To: <20050908105745.GA5847@infradead.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: linux-xfs-bounce@oss.sgi.com
Errors-to: linux-xfs-bounce@oss.sgi.com
Precedence: bulk
Content-Length: 1949
Lines: 46

Christoph Hellwig wrote:
> On Wed, Sep 07, 2005 at 02:45:42PM -0400, Craig Rodrigues wrote:
> 
>>On Wed, Sep 07, 2005 at 07:21:00PM +0100, Christoph Hellwig wrote:
>>
>>>xfs_macros.c is a mess.  If you want to do a service to everyone
>>>kill it and the surrounding machinery and just leave the macros,
>>>without the out of line instances.
>>
>>I don't like xfs_macros.c either, but my understanding
>>was that it still needs to be around, so as not to diverge
>>from the Irix code.  At least that is my understanding
>>based on reading this thread:
>>http://oss.sgi.com/archives/linux-xfs/2004-01/msg00187.html
> 
> 
> That was about changing them to functions, which is a) an intrusive
> change and b) very debatable.  Just leave the macros and remove the
> whole expand the macros to out of line functions alternatively logic.
> If one of them is to big we can change it to a function call later
> more easily after this initial change.
> 

I can give you some history on this if it helps

There were a couple of reasons for the functions vs macros thing (it
predates me too, so don't blame me for the code ;-).

1. Being able to compile as functions meant breakpoints could be
    used in the code. I do not remember the last time that happened.

2. There were some Irix platforms with more limited kernel address
    spaces, for these, a tradeoff was made between speed (inline code
    via a macro), and the space it used. Apart from embedded systems
    which might want to use XFS for some reason, I suspect this is no
    longer an issue, I do not have a good feel for what the smallest
    XFS code size vs the biggest might be.

If someone converts all the code to plain macros, I suggest you look
carefully at the ones which default to being functions, these are
probably the main culprits when it comes to code bloat. With today's
fast cpus, keeping them as functions might still be worth while
from a code size point of view.

Steve