From: Jie Liu <jeff.liu@oracle.com>
To: Anand Jain <Anand.Jain@oracle.com>
Cc: linux-btrfs@vger.kernel.org, dsterba@suse.cz, chris.mason@fusionio.com
Subject: Re: [PATCH] Btrfs: Add get/set label ioctl
Date: Thu, 30 Aug 2012 15:22:57 +0800 [thread overview]
Message-ID: <503F14D1.1080506@oracle.com> (raw)
In-Reply-To: <503F082A.4070603@oracle.com>
On 08/30/12 14:28, Anand Jain wrote:
>
>> The original patch could be revised with this support easily.
>> How about using one structure and one ioctl number for both of them?
>> i.e,
>>
>> #define BTRFS_IOC_FSLABEL_CTL _IOW(BTRFS_IOCTL_MAGIC, 50, struct
>> btrfs_ioctl_fslabel_ctl_args)
>>
>> #define BTRFS_FSLABEL_CTL_GET 0
>> #define BTRFS_FSLABEL_CTL_SET 1
>>
>> struct btrfs_ioctl_fslabel_ctl_args {
>> char label[BTRFS_LABEL_SIZE];
>> u32 flags;
>> };
>>
>> so that get/set label from user tools would looks like,
>>
>> struct btrfs_ioctl_fslabel_ctl_args arg;
>> arg.flags = BTRFS_FSLABEL_CTL_GET; /* get label */
>> or
>> arg.flags = BTRFS_FSLABEL_CTL_SET; /* set label */
>> ....
>>
>> ioctl(fd, BTRFS_FSLABEL_CTL,&arg);
>
>
> I would prefer separating GET and SET label ioctl,
> (to have one operation with an ioctl define) that
> will be similar to rest of the ioctl in btrfs.
> Further we don't need ioctl-arg-struct here, unless
> if you are keeping the flags.
>
Thanks for the suggestions.
Yes, I noticed Btrfs perform add/rm devices, as well as set/set flags,
etc... all with two separated ioctls,
It's better to make the code style in a manner consistent with them.
However, get/set label is assigned one number in previous, the next
number(51) has been assigned to David,
51 - compressed file size - David Sterba
To make the code style in a consistent manner,
We can re-assign those numbers if Chris and David would happy to hear that.
> And in my understanding in kernel memcpy are better
> instead of strcpy.
If we do copy binary structure/elements, memcpy is nice.
However, consider we're copying a label in string, I think the
difference between them in kernel is
same to the user lib, which means that the copy is stops or not when it
encounters a NUL.
By contrast , I think strcpy is better here, if the label is specified
with a NUL('\0', why do that?) in the middle of it,
and we do memcpy for it in kernel, but, the user will get surprised
when he/she fetch the label and printf(3) it out.
Thanks,
-Jeff
>
> If you could add GET that will be nicer.
>
> I would need this for an experiment to add the label
> for the subvol/snapshots.
>
> Thanks, Anand
prev parent reply other threads:[~2012-08-30 7:23 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-29 8:46 [PATCH] Btrfs: Add get/set label ioctl Anand jain
2012-08-29 8:46 ` [PATCH] Btrfs-progs: " Anand jain
2012-08-30 18:27 ` Goffredo Baroncelli
2012-09-14 6:03 ` [PATCH 1/1] Btrfs-progs: Update btrfs man page to indicate label for a mounted fs can be changed Anand jain
2012-08-29 9:00 ` [PATCH] Btrfs: Add get/set label ioctl Jie Liu
2012-08-30 1:54 ` Anand Jain
2012-08-30 5:44 ` Anand Jain
2012-08-30 5:55 ` Jie Liu
2012-08-30 6:04 ` Jie Liu
2012-08-30 6:28 ` Anand Jain
2012-08-30 7:22 ` Jie Liu [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=503F14D1.1080506@oracle.com \
--to=jeff.liu@oracle.com \
--cc=Anand.Jain@oracle.com \
--cc=chris.mason@fusionio.com \
--cc=dsterba@suse.cz \
--cc=linux-btrfs@vger.kernel.org \
/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.