From: Eryu Guan <eguan@redhat.com>
To: Gwendal Grignou <gwendal@chromium.org>
Cc: fstests@vger.kernel.org, Mike Frysinger <vapier@chromium.org>
Subject: Re: xfstest and chromeos
Date: Thu, 26 Jan 2017 13:14:49 +0800 [thread overview]
Message-ID: <20170126051449.GO1859@eguan.usersys.redhat.com> (raw)
In-Reply-To: <CAMHSBOWq5oFTgpZ1hT_Nd7ebVc2nEp8yLp3CFB146fPmizOkEQ@mail.gmail.com>
On Mon, Jan 23, 2017 at 09:57:15AM -0800, Gwendal Grignou wrote:
> I am adding xfstest to chromeos test image, to improve chromeos
> filesystems test coverage.
> Doing so, I encountered to issues, documented in
> https://chromium-review.googlesource.com/#/c/424372
> and
> https://chromium-review.googlesource.com/#/c/424191
>
> https://chromium-review.googlesource.com/#/c/424372
> - To circuvent SELinux protection we add a mount context option,
> requesting to use nfs_t context. However on chromeos, we have no nfs
> security context - we are not expecting usings nfs - leading to a
> mount error. Shall we try to use another context or check beforehand
> if a context is needed for mount?
The selinux context is there because without it some quota or xattr
tests will fail due to extra xattr set by selinux.
I'm not sure what context works for chromeos, but I think we can make
SELINUX_MOUNT_OPTIONS configurable, and it defaults to current value. So
that chromeos could use any context that works for it.
>
> https://chromium-review.googlesource.com/#/c/424191
> - Chromeos needs libtool to (cross-)compile packages and put them at
> the right place. I needed to move archived aclocal.m4 to acinclude.m4.
> Does it make sense to require aclocal to run to compile xfstests?
Sorry, I'm not that familiar with all the autotools build system.. I may
need some time to look into it. Or someone else who is familiar with it
could provide some inputs here?
Thanks,
Eryu
next prev parent reply other threads:[~2017-01-26 5:14 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-23 17:57 xfstest and chromeos Gwendal Grignou
2017-01-26 5:14 ` Eryu Guan [this message]
2017-01-26 7:17 ` Mike Frysinger
2017-01-27 3:45 ` Theodore Ts'o
2017-01-27 8:40 ` Mike Frysinger
2017-01-27 16:37 ` Theodore Ts'o
2017-01-27 18:02 ` Mike Frysinger
2017-01-27 19:31 ` Gwendal Grignou
2017-01-27 21:10 ` Theodore Ts'o
2017-03-06 22:14 ` [PATCH] Make SELinux protection conditional Gwendal Grignou
2017-03-07 0:56 ` xfstest and chromeos Mike Frysinger
2017-03-20 21:20 ` [PATCH] Code to allow cros-compilation on chromeOS Gwendal Grignou
2017-03-24 4:23 ` Eryu Guan
2017-03-24 23:53 ` Gwendal Grignou
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170126051449.GO1859@eguan.usersys.redhat.com \
--to=eguan@redhat.com \
--cc=fstests@vger.kernel.org \
--cc=gwendal@chromium.org \
--cc=vapier@chromium.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox