[LTP] [PATCH v2 2/3] Add fanotify_get_supported_init_flags() helper function

[Amir Goldstein]

On Mon, Oct 24, 2022, 12:03 PM Martin Doucha <mdoucha@suse.cz> wrote:

> On 21. 10. 22 21:03, Amir Goldstein wrote:
> > I don't have a vision of what you are proposing.
> > Make a proposal and I will see if it is correct.
> >
> > I must say I don't understand what it is that you are trying to improve.
> > All the test needs to know is if the specific combinations of flags that
> > the test uses are supported by the kernel/fs.
> >
> > Trying to figure out which of the bits from a specific combination is
> > not supported? how does that help users?
> > Maybe in kernel 5.10 flag X is supported and in kernel 5.11 flag
> > Y is also supported, but only in kernel 5.12 the combination X | Y
> > is supported? Do you see why your generic function doesn't make
> > much sense? or is just too complex to be worth the trouble
> > for an informational print?
>
> The function I'm trying to write is supposed to check whether a
> particular flag is implemented by the kernel. Whether a particular
> combination of implemented flags is also *allowed* is out of scope.
>
> Note that the test I'm writing this for is fanotify14, which checks that
> various invalid combinations of flags will correctly return error. But
> since the error code for "this flag is not implemented" and "this flag
> was used incorrectly" is the same, I need to somehow get the fanotify
> feature set so that I can skip test cases which are not compatible with
> the running kernel. I don't really care about which specific flag is not
> implemented, comparing flags against a bitmask is just a quick and
> convenient way to check that running the test case makes sense.
>


Why is skipping the test better than passing the test?

The test wants to know that a specific flag combination is not allowed.

It is particarly not allowed also on old kernels that do not support either
individual flag.

What's the difference?

Who is going to gain anything from this change?

Sorry for being strict on this point
I may be missing something.

Please clarify what it is the problem use case is and I will suggest a
solution, because I disagree with this solution.

Thanks,
Amir.


> --
> Martin Doucha   mdoucha@suse.cz
> QA Engineer for Software Maintenance
> SUSE LINUX, s.r.o.
> CORSO IIa
> Krizikova 148/34
> 186 00 Prague 8
> Czech Republic
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linux.it/pipermail/ltp/attachments/20221024/e7641bc0/attachment.htm>