[prev in list] [next in list] [prev in thread] [next in thread] 

List:       busybox
Subject:    Re: [PATCH v2 6/9] loop:refactor: Use a structure to reduce parameters
From:       Xiaoming Ni <nixiaoming () huawei ! com>
Date:       2022-11-21 7:27:06
Message-ID: cef72211-36e2-41b7-9510-897a4f30851e () huawei ! com
[Download RAW message or body]

On 2022/11/21 12:28, Kang-Che Sung wrote:
> On Mon, Nov 21, 2022 at 9:31 AM Xiaoming Ni <nixiaoming@huawei.com> wrote:
>>> Also, it is unclear why there is the need to clone the loopinfo buffer.
>>>
>>>   >                 /* Old kernel, does not support LO_FLAGS_AUTOCLEAR? */
>>>   >                 /* (this code path is not tested) */
>>>   > -               loopinfo.lo_flags -= BB_LO_FLAGS_AUTOCLEAR;
>>>   > -               rc = ioctl(lfd, BB_LOOP_SET_STATUS, &loopinfo);
>>>   > +               loopinfo2.lo_flags -= BB_LO_FLAGS_AUTOCLEAR;
>>>   > +               rc = ioctl(lfd, BB_LOOP_SET_STATUS, &loopinfo2);
>>>   >         }
>>>   >         if (rc == 0) {
>>>   >                 return lfd;
>> ...
>>
> 
> Pardon for my ignorance, but does the LOOP_SET_STATUS64 ioctl modify
> the `loopinfo` object internally?

in linux kernel, drivers/block/loop.c:
static int
loop_set_status(struct loop_device *lo, const struct loop_info64 *info)

static int
loop_set_status64(struct loop_device *lo, const struct loop_info64 
__user *arg)

> If the answer is yes, then it might not be a good idea to pass the
> `loopinfo` structure to set_loop_configure().
> I think it might be better to create the object on the fly (i.e. drop
> this patch).
> Otherwise, let set_loop_configure pass in a `const bb_loop_info *`
> object, when we are sure it would never be modified internally.
thanks
  I'll add const modifiers in the next version.

Thanks

_______________________________________________
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
[prev in list] [next in list] [prev in thread] [next in thread]