[PATCH v2] Mount /tmp as tmpfs in test-container and run utime tests in it

[Carlos O'Donell]

On 3/11/21 1:59 PM, Mike Frysinger wrote:
> On 11 Mar 2021 14:16, Adhemerval Zanella wrote:
>> My main point is such tests are not *unit tests* itself because different
>> than other y2038 interface, like gmtime or like, they *do* require kernel
>> support to work as intended.
> 
> i understand the desire, but i don't think there's actual value in trying to
> be "pure" in our definitions.
> 
> how does a test for an interface glibc exposes know if it's implemented
> entirely in glibc, entirely by the OS, or some other combo or mechanism ?
> we've designed the source layout specifically to allow transparent stacking
> based on a number of factors (e.g. OS and architecture).  is the test
> supposed to check whether some part of the implementation lives under an
> "OS" directory?
> 
> if we cut out all the tests that require an OS (as in, a syscall), then we're
> cutting real deep -- too deep.  plus, we *should* be validating how glibc is
> calling the OS because we can easily (and have) used syscalls incorrectly.
> 
> it seems more like the debate is over how much effort we should be investing
> in detecting known kernel bugs, and whether we should workaround or notify or
> just let them fail.  trying to frame it as unit or integration or some other
> term feels like a pointless semantic debate.

My point in highlighting the distinction is that there is room for testing both:
* A test that tests 64-bit time on tmpfs (unit test like with a more controlled impl)
* A test that tests 64-bit time on the host /tmp (integration test like)
 
> maybe we need a common "quirks" file or something.  when such a quirk is
> detected, we can log it and point to a wiki page for the user.

We should just XFAIL the test at runtime if we detect a broken fs.

Arjun just posted a patch to do just this and we should review that.

Adding more tests that use tmpfs is icing on the cake.

-- 
Cheers,
Carlos.