[LTP] [PATCH v3] vfs: fix readahead(2) on block devices
Matthew Wilcox
willy@infradead.org
Sun Sep 24 16:35:18 CEST 2023
On Sun, Sep 24, 2023 at 12:30:30PM +0200, Christian Brauner wrote:
> > This ad-hoc approach to testing syscalls is probably not the best idea.
> > Have the LTP considered a more thorough approach where we have a central
> > iterator that returns a file descriptor of various types (the ones listed
> > above, plus block devices, and regular files), and individual syscall
> > testcases can express whether this syscall should pass/fail for each type
> > of fd? That would give us one central place to add new fd types, and we
> > wouldn't be relying on syzbot to try fds at random until something fails.
> >
> > Or something. I'm not an expert on the LTP or testing in general; it
> > just feels like we could do better here.
>
> I honestly would love to see such tests all go into xfstests. IOW,
> general VFS and fs-specific tests should be in one location. That's why
> I added src/vfs/ under xfstests. Having to run multiple test-suites for
> one subsystem isn't ideal. I mean, I'm doing it but I don't love it...
This may well be a subject on which reasonable people can disagree.
I'm going to lay out what I believe the positions of the various
parties are here, and plese feel free to speak up if you feel I'm
mischaracterising anyone.
The LTP people see it as their mandate to test all syscalls. They focus
on getting the correct error code, checking corner cases of the API, etc.
The xfstests people see it as their mandate to test filesystems.
They focus on testing the corner cases of the filesystem.
These are quite different things, and I'm not sure that forcing them
together or moving test-cases from one test-suite to the other makes
sense. I think it's reasonable to have two separate test suites for you
(and the various bots) to run, even though it's slightly more work.
At the end of the day, I don't much care, it doesn't significantly affect
my life. If I could see a clear advantage to converting one to the other,
I'd be all for it, but I don't see a compelling reason to put much work
in here.
More information about the ltp
mailing list