[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <D0AL4STCYS9S.2F0HJSH4E3M3B@kernel.org>
Date: Wed, 03 Apr 2024 18:16:09 +0300
From: "Jarkko Sakkinen" <jarkko@...nel.org>
To: "Dave Hansen" <dave.hansen@...el.com>, "Haitao Huang"
<haitao.huang@...ux.intel.com>, <dave.hansen@...ux.intel.com>,
<tj@...nel.org>, <mkoutny@...e.com>, <linux-kernel@...r.kernel.org>,
<linux-sgx@...r.kernel.org>, <x86@...nel.org>, <cgroups@...r.kernel.org>,
<tglx@...utronix.de>, <mingo@...hat.com>, <bp@...en8.de>, <hpa@...or.com>,
<sohil.mehta@...el.com>, <tim.c.chen@...ux.intel.com>
Cc: <zhiquan1.li@...el.com>, <kristen@...ux.intel.com>, <seanjc@...gle.com>,
<zhanb@...rosoft.com>, <anakrish@...rosoft.com>,
<mikko.ylinen@...ux.intel.com>, <yangjie@...rosoft.com>,
<chrisyan@...rosoft.com>
Subject: Re: [PATCH v9 15/15] selftests/sgx: Add scripts for EPC cgroup
testing
On Tue Apr 2, 2024 at 6:42 PM EEST, Dave Hansen wrote:
> On 3/30/24 04:23, Jarkko Sakkinen wrote:
> >>> I also wonder is cgroup-tools dependency absolutely required or could
> >>> you just have a function that would interact with sysfs?
> >> I should have checked email before hit the send button for v10 🙂.
> >>
> >> It'd be more complicated and less readable to do all the stuff without the
> >> cgroup-tools, esp cgexec. I checked dependency, cgroup-tools only depends
> >> on libc so I hope this would not cause too much inconvenience.
> > As per cgroup-tools, please prove this. It makes the job for more
> > complicated *for you* and you are making the job more complicated
> > to every possible person in the planet running any kernel QA.
>
> I don't see any other use of cgroup-tools in testing/selftests.
>
> I *DO* see a ton of /bin/bash use though. I wouldn't go to much trouble
> to make the thing ash-compatible.
>
> That said, the most important thing is to get some selftests in place.
> If using cgroup-tools means we get actual, runnable tests in place,
> that's a heck of a lot more important than making them perfect.
> Remember, almost nobody uses SGX. It's available on *VERY* few systems
> from one CPU vendor and only in very specific hardware configurations.
Ash-compatible is good enough for me, so let's draw the line there.
Ash-compatibility does not cause any major hurdle as can we seen from
Haitao's patch. Earlier version was not even POSIX-compatible, given
that it used hard-coded path.
Most of the added stuff come open coding the tools but in the test
code that is not the big deal, and helps with debugging in the future.
Even right now it helps reviewing kernel patches because it documents
exactly how the feature is seen from user space.
BR, Jarkko
Powered by blists - more mailing lists