All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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 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.