From: "Maurizio Lombardi" <mlombard@bsdbackstore.eu>
To: "Dmitry Bogdanov" <d.bogdanov@yadro.com>,
"Maurizio Lombardi" <mlombard@redhat.com>
Cc: <martin.petersen@oracle.com>, <michael.christie@oracle.com>,
<linux-scsi@vger.kernel.org>, <target-devel@vger.kernel.org>
Subject: Re: [PATCH] target: generate correct string identifiers for PR OUT transport IDs
Date: Sun, 29 Jun 2025 14:16:25 +0200 [thread overview]
Message-ID: <DAZ0DFSD9PQS.1UG92BS9ZTTOZ@bsdbackstore.eu> (raw)
In-Reply-To: <20250627174022.GA19805@yadro.com>
On Fri Jun 27, 2025 at 7:40 PM CEST, Dmitry Bogdanov wrote:
> On Fri, Jun 27, 2025 at 04:52:29PM +0200, Maurizio Lombardi wrote:
>>
>> Fix target_parse_pr_out_transport_id() to
>> return a dynamically allocated string representing the
>> transport ID in a standardized, human-readable format
>> (e.g., naa.xxxxxxxx...) for various SCSI protocol types
>> (SAS, FCP, SRP, SBP).
>
> There is no a single standard how to represent TransportId. There are
> several standards for the same port address. But TransportId itself is
> the single standard to represent different port names in binary format.
> So, the most correct solution would be have TransportId for ACLs and
> to match them.
That's right. I will avoid using the word "standardized", which is not
correct in this context.
>
>>
>> Previously, the function returned a pointer to the raw binary buffer.
>> The caller would then compared it to a human-readable string,
>> which obviously always failed.
>>
>> Now, the function constructs a string using kasprintf()
>> based on the protocol's offset and format:
>>
>> * SAS, FCP, SBP: 64-bit identifier
>> * SRP: 128-bit identifier
>> * iSCSI: duplicates the iqn string to match the new allocation behavior
>
> The caller compares it with a specifically prepared string buffer by
> fabric module in its own way. And they are not corresponded any
> standard and, that especially important, to your code.
> Mostly that string contains only hex-representation without any prefixes.
> You may grep target_setup_session to check which transport
> generates what a string.
Thanks for the hint. I was misled by rtslib which enforces those
prefixes. I will fix it and submit a V2.
Maurizio
prev parent reply other threads:[~2025-06-29 12:23 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-27 14:52 [PATCH] target: generate correct string identifiers for PR OUT transport IDs Maurizio Lombardi
2025-06-27 17:40 ` Dmitry Bogdanov
2025-06-29 12:16 ` Maurizio Lombardi [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=DAZ0DFSD9PQS.1UG92BS9ZTTOZ@bsdbackstore.eu \
--to=mlombard@bsdbackstore.eu \
--cc=d.bogdanov@yadro.com \
--cc=linux-scsi@vger.kernel.org \
--cc=martin.petersen@oracle.com \
--cc=michael.christie@oracle.com \
--cc=mlombard@redhat.com \
--cc=target-devel@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.