From: Bernd Schubert <bernd.schubert@fastmail.fm>
To: Andreas Dilger <adilger@whamcloud.com>
Cc: Ted Ts'o <tytso@mit.edu>,
Bernd Schubert <bernd.schubert@itwm.fraunhofer.de>,
linux-nfs@vger.kernel.org, linux-ext4@vger.kernel.org,
bfields@fieldses.org, hch@infradead.org, yong.fan@whamcloud.com,
linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH 3 2/4] Return 32/64-bit dir name hash according to usage type
Date: Wed, 31 Aug 2011 00:07:24 +0200 [thread overview]
Message-ID: <4E5D5F1C.3020502@fastmail.fm> (raw)
In-Reply-To: <8B32DE36-9AD0-4418-86D8-4E453AA910DB@whamcloud.com>
On 08/20/2011 08:23 AM, Andreas Dilger wrote:
> On 2011-08-19, at 4:29 PM, Ted Ts'o wrote:
>> On Tue, Aug 16, 2011 at 01:54:14PM +0200, Bernd Schubert wrote:
>>> +static inline int is_32bit_api(void)
>>> +{
>>> +#ifdef HAVE_IS_COMPAT_TASK
>>> + return is_compat_task();
>>> +#else
>>> + return (BITS_PER_LONG == 32);
>>> +#endif
>>
>> I assume is_compat_task() is coming from another patch? What is the
>> status of that change?
>
> No, is_compat_task() is upstream for most (all?) of the architectures
> that support hybrid 32-/64-bit operation. It is set at 32-bit syscall
> entry when running on 64-bit architectures.
>
> The only minor error in this patch (fixed with a new version from Bernd)
> is that this should be under CONFIG_COMPAT instead of HAVE_IS_COMPAT_TASK.
Yes sorry again about this. Could you please see patch series v4 please?
>
>> In the case where is_compat_task() is not defined, we can't just test
>> based on BITS_PER_LONG == 32, since even on an x86_64 machine, it's
>> possible we're running a 32-bit binary in compat mode....
>
> It is definitely available on x86_64.
Yep, otherwise it even wouldn't compile, at least not with patch series v4.
Thanks,
Bernd
next prev parent reply other threads:[~2011-08-30 22:07 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-16 11:54 [PATCH 0/2] 32/64 bit llseek hashes (v3) Bernd Schubert
2011-08-16 11:54 ` [PATCH 3 1/4] Add new FMODE flags: FMODE_32bithash and FMODE_64bithash Bernd Schubert
2011-08-16 11:54 ` [PATCH 3 2/4] Return 32/64-bit dir name hash according to usage type Bernd Schubert
2011-08-19 22:29 ` Ted Ts'o
[not found] ` <20110819222951.GC3578-AKGzg7BKzIDYtjvyW6yDsg@public.gmane.org>
2011-08-20 6:23 ` Andreas Dilger
2011-08-30 22:07 ` Bernd Schubert [this message]
[not found] ` <20110816115404.1810393.47239.stgit-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
2011-08-16 11:54 ` [PATCH 3 3/4] nfsd_open(): rename 'int access' to 'int may_flags' in nfsd_open() Bernd Schubert
2011-08-16 11:54 ` [PATCH 3 4/4] nfsd: vfs_llseek() with 32 or 64 bit offsets (hashes) Bernd Schubert
2011-08-23 21:56 ` [PATCH 0/2] 32/64 bit llseek hashes (v3) J. Bruce Fields
[not found] ` <20110823215608.GH25350-uC3wQj2KruNg9hUCZPvPmw@public.gmane.org>
2011-08-30 21:59 ` Bernd Schubert
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=4E5D5F1C.3020502@fastmail.fm \
--to=bernd.schubert@fastmail.fm \
--cc=adilger@whamcloud.com \
--cc=bernd.schubert@itwm.fraunhofer.de \
--cc=bfields@fieldses.org \
--cc=hch@infradead.org \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=tytso@mit.edu \
--cc=yong.fan@whamcloud.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;
as well as URLs for NNTP newsgroup(s).