public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Russell Cattelan <cattelan@thebarn.com>
To: Andi Kleen <ak@suse.de>
Cc: xfs@oss.sgi.com
Subject: Re: [PATCH] Replace XFS bit functions with Linux functions
Date: Wed, 03 Oct 2007 13:20:15 -0500	[thread overview]
Message-ID: <4703DD5F.8080906@thebarn.com> (raw)
In-Reply-To: <200710031958.13422.ak@suse.de>

[-- Attachment #1: Type: text/plain, Size: 1653 bytes --]

Andi Kleen wrote:
>> I would like to keep thing abstracted enough such that it is won't be to
>> difficult keep to map to the FreeBSD bit functions.
>>     
>
> It's no different to map linux bit functions to FreeBSD than mapping
> XFS bit functions to FreeBSD. Besides I expect it has fls already -- 
> that is actually a BSDism.
>
>   
Yes but for the most part the common code does not play favorites
to linux or bsd or X in terms of which platform is favored. (with some 
execptions).
I have been working getting the freebsd xfs code based updated and I've 
come
across calls to spin_lock that may need to redone.  I need to look at 
the XFS code
paths more to figure out which freebsd lock is needed.
For the most part freebsd tries not to use mutex spin_lock (disable 
interrupts and spin) since it is
more expensive that just mtx_lock (do not disable interrupts and spin 
for awhile then sleep)
and unless there is a good reason to disable interrupts they try 
avoiding doing so.

Playing favorites is kinda what has fueled this whole "ported half of 
irix to linux" FUD
that has dogged xfs forever.
So for the same reason that people complained about mapping irix calls 
to linux calls
I don't like the argument that linux calls should just be mapped to bsd 
calls.

And I agree with Dave the -1 adjustments are bit hard to follow and would
be better encapsulated in a inline call where it can be documented.

Having the xfs_ call in the common code would also allow the fbsd port 
to catch up with
this optimization  as some point vs having to back stitch the current 
code into  common layer
and eventually having to realign.

> -Andi
>
>   


[-- Attachment #2: cattelan.vcf --]
[-- Type: text/x-vcard, Size: 131 bytes --]

begin:vcard
fn:Russell Cattelan
n:Cattelan;Russell
email;internet:cattelan@thebarn.com
x-mozilla-html:FALSE
version:2.1
end:vcard


      reply	other threads:[~2007-10-03 18:20 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-02  8:10 [PATCH] Replace XFS bit functions with Linux functions Andi Kleen
2007-10-02  9:55 ` Christoph Hellwig
2007-10-02 10:11   ` Andi Kleen
2007-10-02 12:59 ` David Chinner
2007-10-02 13:35   ` Andi Kleen
2007-10-02 16:37 ` Russell Cattelan
2007-10-03 17:58   ` Andi Kleen
2007-10-03 18:20     ` Russell Cattelan [this message]

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=4703DD5F.8080906@thebarn.com \
    --to=cattelan@thebarn.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