io-uring.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Pavel Begunkov <asml.silence@gmail.com>
To: Ammar Faizi <ammarfaizi2@gnuweeb.org>,
	Eli Schwartz <eschwartz93@gmail.com>
Cc: Jens Axboe <axboe@kernel.dk>,
	io-uring Mailing List <io-uring@vger.kernel.org>
Subject: Re: [PATCH liburing 3/4] tests: add tests for zerocopy send and notifications
Date: Mon, 25 Jul 2022 15:07:41 +0100	[thread overview]
Message-ID: <607cd14d-c1a6-52d2-0984-d67f04edf63f@gmail.com> (raw)
In-Reply-To: <7ed1000e-9d13-0d7f-80bd-7180969fec1c@gnuweeb.org>

On 7/25/22 13:08, Ammar Faizi wrote:
> On 7/25/22 6:28 PM, Pavel Begunkov wrote:
>> Don't see any reason for that
> 
> Not that important, just for easy finding. Especially when the number of tests
> increase. And yes, it always increases from time to time.
> 
>> especially since it's not sorted.
> 
> It was, but since that skip-cqe.c exists, it's no longer :p
> OK, OK, that's trivial, never mind. Let's move on.
> 
>>> New test should use the provided exit code protocol. This should have
>>> been "return T_EXIT_SKIP;"
>>
>> Oh, I already hate those rules, sounds like they were specifically
>> honed to make patching harder.
> 
> Lol, how damn hard is it to use it.

Not hard to use, I agree, but it's rather yet another thing that
I need to keep in mind and then it unavoidably gets forgotten and
makes to spend extra 10 minutes to fix/retest/resend/etc., which
is annoying.

Testing is not the most exciting part, frameworks are usually
trying to simplify writing tests even if there is a learning
curve. Implicit rules make it worse. I wouldn't have been
complaining if the compiler failed the build or at least
runtests.sh warned about it.


>> By the way, while we're at it, what is T_EXIT_ERROR? Why it's not used anywhere
>> and how it's different from T_EXIT_FAIL?
> 
> [ Adding Eli to the participants. ]
> 
> Ummm... yeah. I am curious about it too now. I just took a look at commit:
> 
>     ed430fbeb33367 ("tests: migrate some tests to use enum-based exit codes").
> 
> Eli said:
> 
>      From: Eli Schwartz <eschwartz93@gmail.com>
>      Date: Mon, 27 Jun 2022 14:39:05 -0400
>      Subject: [PATCH] tests: migrate some tests to use enum-based exit codes
> 
>      For maintainability and clarity, eschew the use of integer literals in
>      reporting test statuses. Instead, use a helper enum which contains
>      various values from the GNU exitcode protocol. Returning 0 or 1 is
>      obvious, and in the previous commit the ability to read "skip" (77) was
>      implemented. The final exit status is 99, which indicates some kind of
>      error in running the test itself.
> 
>      A partial migration of existing pass/fail values in test sources is
>      included.
> 
>      Signed-off-by: Eli Schwartz <eschwartz93@gmail.com>
> 
> 
> That T_EXIT_ERROR is 99 here. Not sure when to use it in liburing test. Eli?
> 
> [ Just for reference in case you (Eli) want to see the full message:
> 
>    https://lore.kernel.org/io-uring/c89d373f-bc0d-dccf-630f-763e8e1a0fe5@gmail.com/  ]
> 

-- 
Pavel Begunkov

  reply	other threads:[~2022-07-25 14:08 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-25 10:03 [PATCH liburing 0/4] zerocopy send headers and tests Pavel Begunkov
2022-07-25 10:03 ` [PATCH liburing 1/4] io_uring.h: sync with kernel for zc send and notifiers Pavel Begunkov
2022-07-25 10:03 ` [PATCH liburing 2/4] liburing: add zc send and notif helpers Pavel Begunkov
2022-07-25 10:20   ` Ammar Faizi
2022-07-25 11:18     ` Pavel Begunkov
2022-07-25 10:03 ` [PATCH liburing 3/4] tests: add tests for zerocopy send and notifications Pavel Begunkov
2022-07-25 10:35   ` Ammar Faizi
2022-07-25 11:28     ` Pavel Begunkov
2022-07-25 12:08       ` Ammar Faizi
2022-07-25 14:07         ` Pavel Begunkov [this message]
2022-07-25 18:55         ` Eli Schwartz
2022-07-25 23:37           ` Jens Axboe
2022-07-26  9:35             ` Ammar Faizi
2022-07-25 10:03 ` [PATCH liburing 4/4] examples: add a zerocopy send example 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=607cd14d-c1a6-52d2-0984-d67f04edf63f@gmail.com \
    --to=asml.silence@gmail.com \
    --cc=ammarfaizi2@gnuweeb.org \
    --cc=axboe@kernel.dk \
    --cc=eschwartz93@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;
as well as URLs for NNTP newsgroup(s).