From: nscott@aconex.com
To: Andi Kleen <ak@suse.de>
Cc: xfs@oss.sgi.com
Subject: Re: [PATCH] XFS bitops to Linux again
Date: Fri, 5 Oct 2007 06:42:31 +1000 (EST) [thread overview]
Message-ID: <34787.192.168.3.1.1191530551.squirrel@mail.aconex.com> (raw)
In-Reply-To: <200710041014.22936.ak@suse.de>
Hi Andi,
>> Several of these call sites are also compiled in userspace in libxfs.
>> It
>> would
>> be a good idea from that POV also to keep some level of abstraction so
>> that
>> these calls can be mapped to userspace routines as well.
>
> Again the same argument applies -- there is no difference if you
> map xfs_(high|low)bit or fls64/fls/find_find_bit() to something else.
Yep, indeed. I guess what I'm saying is "just make sure userspace is
fixed up
too". So, when you say "if you map...", instead say "when I did that
mapping it
wasn't a problem... patch is included" so that other people (i.e. Barry
here) get
less work to do to on the merge (and don't have to cleanup your cleanup).
>
>> What testing was done? Changes to some of these routines has introuced
>> subtle log recovery bugs in the past - has recovery been tested at all?
>> The QA
>> suite has some log recovery tests, it'd be a good idea to verify with
>> those..
>
> I had a simple separate unit test to verify the 32bit space gave the same
> result. The only difference was the 0 case, but I checked all inputs
> manually. Usually they had != 0 tests already or zero was impossible;
> in the few cases were not I added ASSERTs -- so if i got it wrong it
> should
> bomb out quickly.
Great. You're light years ahead of the rest of the cleanup brigade. :)
> I did also some simple tests using the QA suite -- i believe a few logs
> were recovered -- but not the full tests.
>From a quick look, tests 085, 086 and 087 are the ones I was thinking of
yesterday.
>> To be honest, this sounds like just code churn and risk
>> introduction.
>
> Ok I got the message. I retract the patch. Sorry for bothering you
> with lowly cleanups.
Hey, I like cleanup as much as the next guy (as long as the next guy isn't
Eric,
he just lives to clean ;) - also always ignores userspace despite knowing
better)
- I just don't like seeing more work introduced for the people really
fixing stuff.
I'm sure the patch could be merged (given its been tested) if either
userspace is
updated too, or the same xfs_* naming convention was kept so that userspace
needs no changes.
cheers.
--
Nathan
next prev parent reply other threads:[~2007-10-04 20:44 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-10-03 22:27 [PATCH] XFS bitops to Linux again Andi Kleen
2007-10-03 22:58 ` nscott
2007-10-04 8:14 ` Andi Kleen
2007-10-04 13:11 ` Eric Sandeen
2007-10-04 20:42 ` nscott [this message]
2007-10-04 21:10 ` Eric Sandeen
2007-10-04 23:08 ` David 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=34787.192.168.3.1.1191530551.squirrel@mail.aconex.com \
--to=nscott@aconex.com \
--cc=ak@suse.de \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox