On Thu, Nov 30, 2017 at 7:39 PM, Luis R. Rodriguez <mcgrof@xxxxxxxxxx> wrote:
On Thu, Nov 30, 2017 at 02:17:11PM +0100, Jessica Yu wrote:
Just some quick questions - are there any plans to use these in-kernel
module aliases anywhere else? Or are you using them just for debugging?
As-is for now just debugging, but this could also more easily enable folks to
prototype further evaluation of its uses. IMHO just having this at least posted
online should suffice the later aspect of enabling folks to prototype.
I confirm that, after the module auto-load discussion where it is
clear that we need to improve the infrastructure, this debug
information may save some time, maybe someone can automate a script go
through modules and then on filesystem,
however these patches may show
which module lead to load another one, right ? on userspace if there
are multiple dependencies it can be difficult I think.
You're right that one can find aliases in userspace. One of the benefits
of having this dump things on the kernel log is just that you can easily
get the aliases printed out for all modules actually loaded for your system
without much effort. I did find this useful when debugging and found it much
more convenient than scraping modules one by one by hand in userspace.
I had this implemented since 2016, and I had some ideas to use them in a
functional way, however I first had to knock out a series of of fixes for
kernel/kmod.c and setting up a baseline test infrastructure for kmod
(tools/testing/selftests/kmod/ and lib/test_kmod.c) as such I hadn't had time
to yet come around and finish benchmarking the alias enhancement ideas I had
started evaluating.
As such having aliases in-kernel currently are only useful for debugging and
prototyping.
I would say so, however no strong argument if it should be mainlined.
Luis in your commit log you say:
"Obviously userspace can be buggy though, and it can lie to us. We
currently have no easy way to determine this."
Could you please share some info here ? how userspace can be buggy ?