All of lore.kernel.org
 help / color / mirror / Atom feed
From: 王旭 <xuw2015@gmail.com>
To: Eric Sandeen <sandeen@redhat.com>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: [PATCH] btrfs-progs: fix btrfs quota rescan failed on PPC64 arch
Date: Tue, 21 Apr 2015 10:26:23 +0800	[thread overview]
Message-ID: <CAPBX1x+0kHqhWeq91X3f1XV7RR5=GrOjs1c7t7k+P+nyyk2_XQ@mail.gmail.com> (raw)
In-Reply-To: <5535119E.3050005@redhat.com>

Thanks for review.

On Mon, Apr 20, 2015 at 10:47 PM, Eric Sandeen <sandeen@redhat.com> wrote:
> On 4/20/15 12:33 AM, xuw2015@gmail.com wrote:
>> From: George Wang <xuw2015@gmail.com>
<snip>
>> This means the value "_IOW*" will be negative when we store it in the int
>> variables. Such as the "BTRFS_IOC_QGROUP_CREATE", it will be "0x4010942e" on
>> X86_64, but "0x8010942e" on PPC64.
>> Notice that the IOC values are the "unsigned long" type, so we use the
>> "unsigned long" to store it, and this can insure the comparison between the
>> variable and BTRFS_IOC_* valid.
>
> Looks good - very strange that the manpage states that the interface takes
> an int.  :(

I think maybe the manpage of ioctl is stale. But int can also work
except for comparison.
And fortunately the kernel interface is unsigned int, such as btrfs:

5217 long btrfs_ioctl(struct file *file, unsigned int
5218         cmd, unsigned long arg)

>
> But - an "unsigned int" would be enough, right?  I don't think it needs
> to be an unsigned long.  *shrug*

unsigned int will be OK. But the btrfs-progs is user space, so the
ioctl I think it should be
consistent with the glibc:
/usr/include/sys/ioctl.h:extern int ioctl (int __fd, unsigned long int
__request, ...) __THROW;
unsigned long int is same with unsigned long. So maybe the unsigned
long will be better?

Thanks,
George

  reply	other threads:[~2015-04-21  2:26 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-20  5:33 [PATCH] btrfs-progs: fix btrfs quota rescan failed on PPC64 arch xuw2015
2015-04-20 14:47 ` Eric Sandeen
2015-04-21  2:26   ` 王旭 [this message]
2015-04-22 16:04     ` David Sterba
2015-04-23 17:13 ` Chandan Rajendra
2015-04-24 13:42   ` David Sterba

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='CAPBX1x+0kHqhWeq91X3f1XV7RR5=GrOjs1c7t7k+P+nyyk2_XQ@mail.gmail.com' \
    --to=xuw2015@gmail.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=sandeen@redhat.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.