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 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).