Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20210805043503.20252-1-bvanassche@acm.org> <20210805043503.20252-4-bvanassche@acm.org>
 <20210809145953.GB21234@lst.de> <bcf5fd83-b30a-8887-361e-603821562d9a@acm.org>
 <20210810165029.GA20722@lst.de> <9b1e5c35-1d11-0afa-d382-6f5dc0b14a23@acm.org>
 <e329b0a1-ffe4-9bfa-2bea-33e17da70f58@linuxfoundation.org> <CAFd5g45hMt9OwAVDVuxLNa2EfkTH0tY=KS_qxoUmndPYDvnyig@mail.gmail.com>
In-Reply-To: <CAFd5g45hMt9OwAVDVuxLNa2EfkTH0tY=KS_qxoUmndPYDvnyig@mail.gmail.com>
From:   Brendan Higgins <brendanhiggins@google.com>
Date:   Tue, 1 Mar 2022 15:03:14 -0500
Message-ID: <CAFd5g44vkQ1jiKa1YQ2g8ByHMOiA0rFGS1nRuYk-Dunr-aFHyA@mail.gmail.com>
Subject: Re: [PATCH v4 3/3] configfs: Add unit tests
To:     Bart Van Assche <bvanassche@acm.org>
Cc:     Shuah Khan <skhan@linuxfoundation.org>,
        Christoph Hellwig <hch@lst.de>,
        Joel Becker <jlbec@evilplan.org>, linux-kernel@vger.kernel.org,
        Bodo Stroesser <bostroesser@gmail.com>,
        "Martin K . Petersen" <martin.petersen@oracle.com>,
        Yanko Kaneti <yaneti@declera.com>,
        KUnit Development <kunit-dev@googlegroups.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Wed, Aug 11, 2021 at 5:00 AM Brendan Higgins
<brendanhiggins@google.com> wrote:
>
> On Tue, Aug 10, 2021 at 1:50 PM Shuah Khan <skhan@linuxfoundation.org> wr=
ote:
> >
> > On 8/10/21 12:45 PM, Bart Van Assche wrote:
> > > On 8/10/21 9:50 AM, Christoph Hellwig wrote:
> > >> On Mon, Aug 09, 2021 at 11:31:23AM -0700, Bart Van Assche wrote:
> > >>>>> +config CONFIGFS_KUNIT_TEST
> > >>>>> +    bool "Configfs Kunit test" if !KUNIT_ALL_TESTS
> > >>>>> +    depends on CONFIGFS_FS && KUNIT=3Dy
> > >>>>> +    default KUNIT_ALL_TESTS
> > >>>>
> > >>>> Why does it depend on KUNIT=3Dy?  What is the issue with a modular=
 KUNIT
> > >>>> build?
> > >>>
> > >>> The unit tests calls do_mount(). do_mount() has not been exported a=
nd
> > >>> hence is not available to kernel modules. Hence the exclusion of KU=
NIT=3Dm.
> > >>
> > >> You should probably document that.  But then again this is another
> > >> big red flag that this code should live in userspace.
> > >>
> > >>>> To me this sounds like userspace would be a better place for these
> > >>>> kinds of tests.
> > >>>
> > >>> Splitting the code that can only be run from inside the kernel (cre=
ation
> > >>> of configfs attributes) and the code that can be run from user spac=
e and
> > >>> making sure that the two run in a coordinated fashion would involve=
 a
> > >>> significant amount of work. I prefer to keep the current approach.
> > >>
> > >> But userspace is the right place to do this kind of pathname
> > >> based file system I/O.
> > >
> > > Shuah, as selftest maintainer, can you recommend an approach? How abo=
ut splitting patch 3/3 from this series into a kernel module (the code that=
 creates the configfs test attributes) and user space code (the code that r=
eads and writes the configfs attributes) and adding the user space code in =
a subdirectory of tools/testing/selftests/?
> > >
> >
> > I am missing a lot of context here. I don't see this series in my inbox
> > except patch 2/3 which says:
> >
> > "A common feature of unit testing frameworks is support for sharing a t=
est
> > configuration across multiple unit tests. Add this functionality to the
> > KUnit framework. This functionality will be used in the next patch in t=
his
> > series."
>
> Yeah, I mentioned this to one of the other KUnit people who said he
> might want to post some comments. Bart, could you CC
> kunit-dev@googlegroups.com and/or linux-kselftest@vger.kernel.org
> if/when you send follow-up patches?
>
> Actually, I suppose regardless of what you do with this patch, you
> will probably want to merge via the kselftest tree (KUnit changes and
> many tests go through the kselftest tree as well). So, you should
> probably CC linux-kselftest@vger.kernel.org no matter what.
>
> > That doesn't tell me much other than what happens that it is a common u=
nit
> > testing framework without explaining why it should be done this way.
> >
> > Taking a quick look at the original message on lore - I agree with Chri=
stoph
> > that this code belongs in userspace. I would like to see the division o=
f
> > kernel userspace.
> >
> > Why do the unit tests need to call do_mount() - can whatever the unit t=
ests
> > are currently doing can be done from userspace.
> >
> > If part of the test code must live in kernel space then kernel test mod=
ule
> > approach can be used.

I am not sure if you are still working on this test or not, but Kees
recently posted a patch to create a KUnit UAPI:
https://lore.kernel.org/lkml/20220227184517.504931-8-keescook@chromium.org/

Not sure if you have any interest, or even if this would be the right
tool for the job, but I figured it's worth a look because it might
save you the effort of having to completely rewrite your test.

Cheers