Re: Cyclic Code?

[Dave Chinner <david@fromorbit.com>]

On Mon, Jan 09, 2012 at 11:10:30PM +0530, Amit Sahrawat wrote:
> On Mon, Jan 9, 2012 at 12:22 PM, Adil Mujeeb <mujeeb.adil@gmail.com> wrote:
> > Hi list,
> >
> > i am new to XFS.
> >
> > I was going through XFS code (2.4 based) for study purpose. Its old but
> > assuming its bit simple as compare to latest one. Moreover the XFS code /
> > design structure documents available on the internet is 2.4 based.
> May be if you switch to a version around 2.6.20 nearabout - it will
> make it easier to understand the code. Prior to that the complete XFS
> source code seemed like traversing through a lot of macros... I
> started with 2.6.18 and it was really hard to understand from that
> version...

I'd recommend starting with the current top of tree code - it is
much, much cleaner that the code base even from 2.6.20. Remember, 2.6.20
was released almost 5 years ago (Feb 4 2007), and there's been a
*lot* of cleanup work done since then....

> > The following code snippet is not clear to me (seems cyclic):
> >
> > ---------
> > ...
> > ...
> > #define XFS_IFORK_NEXTENTS(ip,w)        xfs_ifork_nextents(ip,w)
> > ...
> > xfs_ifork_nextents(xfs_inode_t *ip, int w)
> > {
> >         return XFS_IFORK_NEXTENTS(ip, w);
> > }
> I guess you missed something while reading the code.... I tried to
> look at the repositry.. this is how the code looks...
> #if XFS_WANT_FUNCS || (XFS_WANT_SPACE && XFSSO_XFS_IFORK_NEXTENTS)	
>  int xfs_ifork_nextents(xfs_inode_t *ip, int w);	
>  #define XFS_IFORK_NEXTENTS(ip,w)        xfs_ifork_nextents(ip,w)	
>  #else	
>  #define XFS_IFORK_NEXTENTS(ip,w)        XFS_CFORK_NEXTENTS(&ip->i_d, w)	
>  #endif
> ....
> #define XFS_CFORK_NEXTENTS(dcp,w) \
> 	((w) == XFS_DATA_FORK ? (dcp)->di_nextents : (dcp)->di_anextents)

Yup, that XFS_WANT_FUNCS crap was for debugging the macros because
they were too complex to debug in line. That went long ago.

FYI, macros were very popular in Irix code - desite SGI having an
awesome compiler, the SGI kernel engineers believed that function
calls were just too expensive to call and so macros that expanded
out to 300 lines of code were common. Hence the need to have some
way of debugging them.

Hell, I know one engineer used to compile the code and then
disassemble in the debugger on the running machine because that was
the *simplest way* to work out what code the macros actually
compiled in. :-O

I'm glad we've got rid of most of the macro-instead-of-function
usage now...

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs