From: Aurelien Aptel <aaptel@nvidia.com>
To: Shinichiro Kawasaki <shinichiro.kawasaki@wdc.com>
Cc: "linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
"linux-nvme@lists.infradead.org" <linux-nvme@lists.infradead.org>,
Daniel Wagner <dwagner@suse.de>,
Chaitanya Kulkarni <chaitanyak@nvidia.com>,
Shai Malin <smalin@nvidia.com>
Subject: Re: [PATCH blktests v4 1/5] nvme/rc: introduce remote target support
Date: Mon, 02 Dec 2024 12:23:41 +0200 [thread overview]
Message-ID: <2534j3mv0wi.fsf@nvidia.com> (raw)
In-Reply-To: <ghcsy46j652pvawoikkpym4buqo2hmimrvxrfnetlmqjnkvxr2@kncqoxdc77zi>
Shinichiro Kawasaki <shinichiro.kawasaki@wdc.com> writes:
>> @@ -208,6 +213,18 @@ _cleanup_nvmet() {
>>
>> _setup_nvmet() {
>> _register_test_cleanup _cleanup_nvmet
>> +
>> + if [[ -n "${nvme_target_control}" ]]; then
>> + def_hostnqn="$(${nvme_target_control} config --show-hostnqn)"
>> + def_hostid="$(${nvme_target_control} config --show-hostid)"
>> + def_host_traddr="$(${nvme_target_control} config --show-host-traddr)"
>
> I suggest to remove the line above. It caused ShellCheck warning SC2034. I think
> def_host_traddr is not used anywhere.
Ok.
>> @@ -811,6 +836,29 @@ _nvmet_target_setup() {
>> fi
>> fi
>>
>> + if [[ -n "${hostkey}" ]]; then
>> + ARGS+=(--hostkey "${hostkey}")
>> + fi
>> + if [[ -n "${ctrlkey}" ]]; then
>> + ARGS+=(--ctrkey "${ctrlkey}")
>> + fi
>
> This part above sets arguments --hostkey and --ctrkey in ARGS to pass to
> _create_nvmet_subsystem(), but I find that _create_nvmet_subsystem() does not
> refer to the arguments. Though I know this part was in v3 also, I suggest drop
> this part.
Good point.
>> +
>> + if [[ -n "${nvme_target_control}" ]]; then
>> + eval "${nvme_target_control}" setup \
>> + --subsysnqn "${subsysnqn}" \
>> + --subsys-uuid "${subsys_uuid:-$def_subsys_uuid}" \
>> + --hostnqn "${def_hostnqn}" \
>> + "${ARGS[@]}" &> /dev/null
>
> The line above causes the ShellCheck warning SC 2294. Let's replace ${ARGS[@]}
> with ${ARGS[*]}.
I think using quoting [*] will merge the args as one and is not what we
want. I will remove the eval instead. It came from v3, not sure why it is
needed.
>> + return
>> + fi
>> +
>> + truncate -s "${NVME_IMG_SIZE}" "$(_nvme_def_file_path)"
>> + if [[ "${blkdev_type}" == "device" ]]; then
>> + blkdev="$(losetup -f --show "$(_nvme_def_file_path)")"
>> + else
>> + blkdev="$(_nvme_def_file_path)"
>> + fi
>
> This truncate and blkdev setup part causes failure of nvme/052:
> [...]
> Also, this part looks duplicated with the other part in _nvmet_target_setup().
> Please see the 'if [[ "${blkdev_type}" != "none" ]]' block.
You're correct, this was a rebasing mistake. I will remove it.
> I guess this is the part you added "to specify the backing block device on the
> target, instead of hardcoding '/dev/vdc'". If so, I think such changes should
> be done under 'if [[ -n "${nvme_target_control}" ]]' condition.
No that part is done in the contrib/ script and the template.
Thanks
next prev parent reply other threads:[~2024-12-02 10:23 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-26 20:38 [PATCH blktests v4 0/5] Add support to run against arbitrary targets Aurelien Aptel
2024-11-26 20:38 ` [PATCH blktests v4 1/5] nvme/rc: introduce remote target support Aurelien Aptel
2024-11-29 10:01 ` Shinichiro Kawasaki
2024-12-02 10:23 ` Aurelien Aptel [this message]
2024-11-26 20:38 ` [PATCH blktests v4 2/5] common/nvme: add digest options to __nvme_connect_subsys() Aurelien Aptel
2024-11-26 20:38 ` [PATCH blktests v4 3/5] nvme/030: only run against kernel soft target Aurelien Aptel
2024-11-26 20:38 ` [PATCH blktests v4 4/5] contrib: add remote target setup/cleanup script Aurelien Aptel
2024-11-26 20:38 ` [PATCH blktests v4 5/5] nvme/055: add test for nvme-tcp zero-copy offload Aurelien Aptel
2024-11-29 10:20 ` Shinichiro Kawasaki
2024-12-02 10:09 ` Aurelien Aptel
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=2534j3mv0wi.fsf@nvidia.com \
--to=aaptel@nvidia.com \
--cc=chaitanyak@nvidia.com \
--cc=dwagner@suse.de \
--cc=linux-block@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=shinichiro.kawasaki@wdc.com \
--cc=smalin@nvidia.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox