Re: [LTP] [PATCH 03/17] lib: tst_kernel: Add tst_check_module_driver()

[Petr Vorel <pvorel@suse.cz>]

> Hi!
> > > > Thinking about it twice, could we check for the module by reading
> > > > /sys/module/? Our current approach shows what module *should* be available, but
> > > > that might not be true for some reason (i.e. loadable module not installed).

> > > The modules.dep file contains names of all modules installed in
> > > particular kernel modules directory. We cannot do anything better than
> > > parsing that file because it's (re)genrated on the system each time
> > > packages with modules have been installed/removed. If that wasn't the
> > > case modprobe that depends on that file wouldn't work either.

> > We effectively ask users to install modules.dep and modules.builtin. While this
> > is ok for distros and nobody has complained, I can imagine special embedded
> > systems can have problem. If everything was reliably detectable via /sys or
> > /proc I'd move to it. But even it's not working for all modules, checking first
> > /sys/module/ and fallback using modules.{builtin,dep} wouldn't take much effort.

> My code does not add any new dependencies. The check for module.dep has
> been in LTP since:

> 8f7013ba6917 ('tst_check_driver(): Fix kernel module detection on BusyBox')

> which was introduced five years ago.

> The only thing that changes is that the check is being moved from
> needs_drivers to needs_kconfigs.

Sure, it's not new dependency and I like this cleanup. My point is not directly
related to the these changes, but to the fact that I probably did not know about
/sys/module/ back then. But I knew the limitations (no detection on Android,
possible problems on embedded).

Kind regards,
Petr

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp