This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: V7 test-in-container patch
- From: DJ Delorie <dj at redhat dot com>
- To: Florian Weimer <fweimer at redhat dot com>
- Cc: libc-alpha at sourceware dot org, joseph at codesourcery dot com, carlos at redhat dot com
- Date: Wed, 15 Aug 2018 19:57:35 -0400
- Subject: Re: V7 test-in-container patch
Florian Weimer <fweimer@redhat.com> writes:
> There are sill a bunch of style issues, visible in:
>
> git show | grep '^+.*[^ ($]('
Fixed.
> There are also a few lines longer than 79 characters.
Fixed. And annoying. It encourages use of short variable names instead
of more self-documenting longer ones. Is anyone still coding on a VT52
terminal these days?
> And two instances
> of this:
>
> git show | grep '\. \*/'
Fixed.
> +#define __USE_LARGEFILE64
>
> That should be:
>
> #define _FILE_OFFSET_BITS 64
Fixed.
> +/* Equivalent of "mkdir -p". */
> +void xmkdirp (const char *, mode_t);
>
> This should probably go into <support/xunistd.h>, not <support/support.h>.
Makes sense. Fixed.
> Hurd doesn't have unshare, so you need to avoid building the container
> framework there.
Is it OK to return UNSUPPORTED for those? I don't think it makes sense
to try to work around the whole containerized-test setup if containers
are missing.
> The Red Hat Enterprise Linux 7 kernel doesn't seem to like this
> combination of flags, even as root:
>
> unshare(CLONE_NEWNS|CLONE_NEWUSER|CLONE_NEWPID) = -1 EINVAL (Invalid
> argument)
>
> Is CLONE_NEWPID really required?
Yes. You can't mount /proc without it. Don't ask me why ;-)
Another case for UNSUPPORTED then?
> My concern about the over-use of FAIL_UNSUPPORTED and the UNSUPPORTED
> test status in the container framework remains. Sure, there are some
> things that can fail due to missing host support, but e.g. a fork file
> shouldn't lead to UNSUPPORTED, but FAIL.
I replaced them all with FAILs. I was trying to keep "failure of the
test" separate from "failure of the test harness" but I'm OK with it
either way.