On Mon, Jul 14, 2025 at 07:52:27AM +0200, Thomas Weißschuh wrote: > (+Luis for the usermode helper discussion) > > On Fri, Jul 11, 2025 at 04:44:23PM +0100, Al Viro wrote: > > On Fri, Jul 11, 2025 at 12:35:59PM +0200, Thomas Weißschuh wrote: > > > Hi Kees, Al, Christian and Honza, > > > > > > On Thu, Jun 26, 2025 at 08:10:14AM +0200, Thomas Weißschuh wrote: > > > > The KUnit UAPI infrastructure starts userspace processes. > > > > As it should be able to be built as a module, export the necessary symbols. > > > > What's wrong with kernel/umh.c? > > It gets neutered by CONFIG_STATIC_USERMODEHELPER_PATH. That could be worked > around be overriding sub_info->path, but it would be a hack. > It does not allow to implement a custom wait routine to forward the process > output to KUnit as implemented in kunit_uapi_forward_to_printk() [0]. > That may be solved by adding another thread, but that would also be hacky. > > It would probably be possible to extend kernel/umh.c for my usecase but I > didn't want bloat the core kernel code for my test-only functionality. > > > > could you take a look at these new symbol exports? > > > > > > +EXPORT_SYMBOL_GPL_FOR_MODULES(put_filesystem, "kunit-uapi"); > > > > What's that one for??? > > What are you referring to? > > The macro EXPORT_SYMBOL_GPL_FOR_MODULES() will only export the symbol for one > specific module. Personally I'm also fine with EXPORT_SYMBOL_GPL(). No, we're going to use the new restricted macros going forward that limit exports to very specific modules. This is a good example. Though it will be renamed to EXPORT_SYMBOL_FOR_MODULES() anyway.
