linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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


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