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

Mike Frysinger vapier@gentoo.org
Thu Mar 11 18:59:55 GMT 2021


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.

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


More information about the Libc-alpha mailing list