Re: [RFC v2 13/16] luo: add selftests for subsystems un/registration

[Pasha Tatashin <pasha.tatashin@soleen.com>]

On Mon, May 26, 2025 at 4:52 AM Mike Rapoport <rppt@kernel.org> wrote:
>
> On Thu, May 15, 2025 at 06:23:17PM +0000, Pasha Tatashin wrote:
> > Introduce a self-test mechanism for the LUO to allow verification of
> > core subsystem management functionality. This is primarily intended
> > for developers and system integrators validating the live update
> > feature.
> >
> > The tests are enabled via the new Kconfig option
> > CONFIG_LIVEUPDATE_SELFTESTS (default 'n') and are triggered through
> > a new ioctl command, LIVEUPDATE_IOCTL_SELFTESTS, added to the
> > /dev/liveupdate device node.
> >
> > This ioctl accepts commands defined in luo_selftests.h to:
> > - LUO_CMD_SUBSYSTEM_REGISTER: Creates and registers a dummy LUO
> >   subsystem using the liveupdate_register_subsystem() function. It
> >   allocates a data page and copies initial data from userspace.
> > - LUO_CMD_SUBSYSTEM_UNREGISTER: Unregisters the specified dummy
> >   subsystem using the liveupdate_unregister_subsystem() function and
> >   cleans up associated test resources.
> > - LUO_CMD_SUBSYSTEM_GETDATA: Copies the data page associated with a
> >   registered test subsystem back to userspace, allowing verification of
> >   data potentially modified or preserved by test callbacks.
> > This provides a way to test the fundamental registration and
> > unregistration flows within the LUO framework from userspace without
> > requiring a full live update sequence.
>
> I don't think ioctl for selftest is a good idea.
> Can't we test register/unregister and state machine transitions with kunit?
>
> And have a separate test module that registers as a subsystem, preserves
> it's state and then verifies the state after the reboot. This will require
> running qemu and qemu usage in tools/testing is a mess right now, but
> still.

Normally, I would agree with you, but LUO is special as it has two
parts: user states and kernel states, and it is already driven through
ioctl() interface to do state transitions, and preservation
management. So, in this particular case having an extended IOCTLs to
configure a specific kernel state, and then use normal IOCTLs to drive
tests is very useful. In the future, I plan to add support to QEMU,
but we need more work for that to happen.

Pasha