All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: Kyle McMartin <kmcmarti@redhat.com>
Cc: sandeen@redhat.com, xfs@oss.sgi.com
Subject: Re: [PATCH] xfsdump: don't assume getdents exists
Date: Thu, 7 Nov 2013 10:17:13 +1100	[thread overview]
Message-ID: <20131106231713.GK6188@dastard> (raw)
In-Reply-To: <20131106225620.GC29593@redacted.bos.redhat.com>

On Wed, Nov 06, 2013 at 05:56:20PM -0500, Kyle McMartin wrote:
> On Thu, Nov 07, 2013 at 09:48:44AM +1100, Dave Chinner wrote:
> > > +++ b/common/getdents.c
> > 
> > Oh, how that code makes my eyes bleed. :/
> > 
> 
> Me too :\
> 
> > > @@ -70,6 +70,9 @@ extern int __have_no_getdents64;
> > >  # ifndef SYS_getdents64
> > >  #  define SYS_getdents64 __NR_getdents64
> > >  # endif
> > > +# ifndef __NR_getdents
> > > +#  define __ONLY_GETDENTS64_SYSCALL     1
> > > +# endif
> > >  #endif
> > >  
> > >  
> > > @@ -207,6 +210,13 @@ getdents_wrap (int fd, char *buf, size_t nbytes)
> > >  # endif
> > >      }
> > >  #endif
> > > +/* Newer Linux ports are not adding deprecated syscalls, so to avoid compile
> > > + * failures since SYS_getdents will be undefined, we check for that and only
> > > + * build the fall-back case if SYS_getdents is defined. We know that
> > > + * __ASSUME_GETDENTS64_SYSCALL is set, since __NR_getdents64 must exist on
> > > + * those platforms.
> > > + */
> > > +#ifndef __ONLY_GETDENTS64_SYSCALL
> > >    {
> > >      size_t red_nbytes;
> > >      struct kernel_dirent *skdp, *kdp;
> > > @@ -265,4 +275,5 @@ getdents_wrap (int fd, char *buf, size_t nbytes)
> > >      }
> > >  
> > >    return (char *) dp - buf;
> > > +#endif
> > >  }
> > 
> > It's not pretty - but that code has already broken the ugly stick so
> > it isn't making the situation any worse.
> > 
> > Acked-by: Dave Chinner <dchinner@redhat.com>
> 
> I'll try to clean it up and send a patch for that, using getdents64
> wherever possible, and handling the fallback at runtime instead of
> making things all ifdeffy... Just wanted to get things building in the
> mean time. (Oh man the coding style there is janky...)

I'd factor and reformat the code using the normal kernel style. :)

And to avoid ifdef hackery and runtime fallbacks, I'd add an
autoconf macro to determine which getdents call is supported, and
then only compile in the relevant function and not have to care
about runtime fallbacks.

But that may end up more complex and more work than you had in mind,
so feel free to ignore my suggestions ;)

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

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

  reply	other threads:[~2013-11-06 23:17 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-06 21:36 [PATCH] xfsdump: don't assume getdents exists Kyle McMartin
2013-11-06 22:48 ` Dave Chinner
2013-11-06 22:56   ` Kyle McMartin
2013-11-06 23:17     ` Dave Chinner [this message]
2013-11-06 23:19       ` Kyle McMartin
2013-11-07  6:58 ` Christoph Hellwig
2013-11-07  7:06   ` Christoph Hellwig
2013-12-10 14:46 ` Eric Sandeen
2013-12-10 19:50   ` Kyle McMartin
2014-03-22  5:12   ` Kyle McMartin
2014-03-22  8:53     ` Dave Chinner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20131106231713.GK6188@dastard \
    --to=david@fromorbit.com \
    --cc=kmcmarti@redhat.com \
    --cc=sandeen@redhat.com \
    --cc=xfs@oss.sgi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.