Re: [PATCH v4 3/3] configfs: Add unit tests

[Brendan Higgins]

On Wed, Aug 11, 2021 at 5:00 AM Brendan Higgins
<brendanhiggins@xxxxxxxxxx> wrote:
>
> On Tue, Aug 10, 2021 at 1:50 PM Shuah Khan <skhan@xxxxxxxxxxxxxxxxxxx> wrote:
> >
> > 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=y
> > >>>>> +    default KUNIT_ALL_TESTS
> > >>>>
> > >>>> Why does it depend on KUNIT=y?  What is the issue with a modular KUNIT
> > >>>> build?
> > >>>
> > >>> The unit tests calls do_mount(). do_mount() has not been exported and
> > >>> hence is not available to kernel modules. Hence the exclusion of KUNIT=m.
> > >>
> > >> 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 (creation
> > >>> of configfs attributes) and the code that can be run from user space 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 about 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 reads 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 test
> > configuration across multiple unit tests. Add this functionality to the
> > KUnit framework. This functionality will be used in the next patch in this
> > 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@xxxxxxxxxxxxxxxx and/or linux-kselftest@xxxxxxxxxxxxxxx
> 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@xxxxxxxxxxxxxxx no matter what.
>
> > That doesn't tell me much other than what happens that it is a common unit
> > testing framework without explaining why it should be done this way.
> >
> > Taking a quick look at the original message on lore - I agree with Christoph
> > that this code belongs in userspace. I would like to see the division of
> > kernel userspace.
> >
> > Why do the unit tests need to call do_mount() - can whatever the unit tests
> > are currently doing can be done from userspace.
> >
> > If part of the test code must live in kernel space then kernel test module
> > 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@xxxxxxxxxxxx/

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