public inbox for io-uring@vger.kernel.org
 help / color / mirror / Atom feed
From: Jens Axboe <axboe@kernel.dk>
To: Pavel Begunkov <asml.silence@gmail.com>, io-uring@vger.kernel.org
Subject: Re: [PATCH 2/2] tests: timestamp example
Date: Mon, 30 Jun 2025 10:47:59 -0600	[thread overview]
Message-ID: <2a2ac741-7952-4b7d-a731-5db7b40ea19f@kernel.dk> (raw)
In-Reply-To: <79255ffd-9985-41f4-b404-4478d11501e5@gmail.com>

On 6/30/25 10:45 AM, Pavel Begunkov wrote:
> On 6/30/25 17:20, Jens Axboe wrote:
>> On 6/30/25 10:09 AM, Pavel Begunkov wrote:
>>> Signed-off-by: Pavel Begunkov <asml.silence@gmail.com>
>>
>> A bit of commit message might be nice? Ditto the other patch.
>> I know they are pretty straight forward, but doesn't hurt to
>> spell out a bit why the change is being made.
> 
> It's not like there is much to describe. The only bit
> I can add is the reference to the selftest as per the CV

Agree, but even a link to the cover letter for the feature would be
nice, then people can at least look it up rather than need to search for
what it is.

>>> +#ifndef SCM_TS_OPT_ID
>>> +#define SCM_TS_OPT_ID 0
>>> +#endif
> 
> Otherwise it needs to be
> 
> #ifdef SCM_TS_OPT_ID
> 
> All tests using SCM_TS_OPT_ID
> 
> #else
> int main() {
>     return skip;
> }
> #endif
> 
> which is even uglier

That's not what I meant, as per below. It was about defining it to
something valid, rather than gate the entire test on the define being
available.

>> This one had me a bit puzzled, particularly with:
>>
>>> +    if (SCM_TS_OPT_ID == 0) {
>>> +        fprintf(stderr, "no SCM_TS_OPT_ID, skip\n");
>>> +        return T_EXIT_SKIP;
>>> +    }
>>
>> as that'll just make the test skip on even my debian unstable/testing
>> base as it's still not defined there. But I guess it's because it's arch
>> specific? FWIW, looks like anything but sparc/parisc define it as 81,
>> hence in terms of coverage might be better to simply define it for
>> anything but those and actually have the test run?
> 
> That only works until someone runs it on those arches and complain,
> i.e. delaying the problem. And I honesty don't want to parse the
> current architecture and figuring the value just for a test.

Since it's just those two obscure archs that nobody uses, I can just add
it after the fact. I'd rather deal with that than not have the test run
just because some arch relics use private defines. Not a big deal.

-- 
Jens Axboe

  reply	other threads:[~2025-06-30 16:48 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-30 16:09 [PATCH 0/2] add tx timestamp tests Pavel Begunkov
2025-06-30 16:09 ` [PATCH 1/2] Sync io_uring.h with tx timestamp api Pavel Begunkov
2025-06-30 16:09 ` [PATCH 2/2] tests: timestamp example Pavel Begunkov
2025-06-30 16:20   ` Jens Axboe
2025-06-30 16:45     ` Pavel Begunkov
2025-06-30 16:47       ` Jens Axboe [this message]
2025-06-30 16:50       ` Pavel Begunkov
2025-06-30 16:54         ` Jens Axboe
2025-06-30 16:55         ` Pavel Begunkov

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=2a2ac741-7952-4b7d-a731-5db7b40ea19f@kernel.dk \
    --to=axboe@kernel.dk \
    --cc=asml.silence@gmail.com \
    --cc=io-uring@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