From: Petr Vorel <pvorel@suse.cz>
To: Martin Doucha <mdoucha@suse.cz>
Cc: Jan Kara <jack@suse.cz>, LTP List <ltp@lists.linux.it>
Subject: Re: [LTP] [PATCH v2 2/3] Add fanotify_get_supported_init_flags() helper function
Date: Tue, 25 Oct 2022 11:41:49 +0200 [thread overview]
Message-ID: <Y1evXZKLHnrs74fo@pevik> (raw)
In-Reply-To: <4ab4ec76-c62f-9aaa-94a7-72e8b75d91cb@suse.cz>
> On 24. 10. 22 19:03, Petr Vorel wrote:
> > > The kernel UAPI is not very consistent about ENOTSUP vs. EINVAL
> > > renameat(2), unlink(2), link(2) and other return EINVAL for unsupported flags
> > > fallocate(2), ioctl(2) and others return ENOTSUP for unsupported commands.
> > > It's not a clear cut, but ENOTSUP is generally for unsupported fs methods,
> > > not for unsupported options.
> > thanks for info, I didn't know that. Otherwise Martin's note to use ENOTSUP
> > would help.
> I was not suggesting to change the kernel API, that's not a reasonable
> option at this point. I was just pointing out that the API design limits our
> options how to write reliable tests.
Sure, that was my suggestion. I meant it more as future improvement than to
solution to our problem, but I wasn't sure myself whether it be a good way.
It just remind me a different case, where errno was changed by accident and
kept that way (fix [1] was not accepted, instead the change was backported to
all live stable/LTS so that errno is at least consistent).
I also wonder whether real users of the API (not just test writers) would
appreciate to distinguish between these two cases. But anyway, I understand that
there would have to be a strong need for it to be reason to change, thus not
acceptable.
Kind regards,
Petr
[1] https://lore.kernel.org/netdev/20170630073448.GA9546@unicorn.suse.cz/
--
Mailing list info: https://lists.linux.it/listinfo/ltp
next prev parent reply other threads:[~2022-10-25 9:42 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-20 13:08 [LTP] [PATCH v2 0/3] Fix fanotify14 Martin Doucha
2022-10-20 13:08 ` [LTP] [PATCH v2 1/3] fanotify14: Print human-readable test case flags Martin Doucha
2022-11-01 14:29 ` Richard Palethorpe
2022-11-03 11:34 ` Richard Palethorpe
2022-10-20 13:08 ` [LTP] [PATCH v2 2/3] Add fanotify_get_supported_init_flags() helper function Martin Doucha
2022-10-20 15:36 ` Amir Goldstein
2022-10-21 13:49 ` Martin Doucha
2022-10-21 19:03 ` Amir Goldstein
2022-10-24 9:03 ` Martin Doucha
2022-10-24 13:08 ` Amir Goldstein
2022-10-24 13:16 ` Martin Doucha
2022-10-24 14:34 ` Amir Goldstein
2022-10-24 14:58 ` Martin Doucha
2022-10-24 16:15 ` Petr Vorel
2022-10-24 16:30 ` Amir Goldstein
2022-10-24 17:03 ` Petr Vorel
2022-10-25 8:37 ` Martin Doucha
2022-10-25 9:41 ` Petr Vorel [this message]
2022-10-24 16:18 ` Amir Goldstein
2022-10-25 8:51 ` Martin Doucha
2022-10-25 9:48 ` Jan Kara
2022-10-25 13:55 ` Martin Doucha
2022-10-25 16:53 ` Amir Goldstein
2022-10-26 14:34 ` Martin Doucha
2023-05-10 18:38 ` Petr Vorel
2022-10-25 11:11 ` Amir Goldstein
2022-10-20 13:08 ` [LTP] [PATCH v2 3/3] fanotify14: Improve check for unsupported init flags Martin Doucha
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=Y1evXZKLHnrs74fo@pevik \
--to=pvorel@suse.cz \
--cc=jack@suse.cz \
--cc=ltp@lists.linux.it \
--cc=mdoucha@suse.cz \
/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