+++ Djalal Harouni [04/12/17 10:01 +0100]:>On Thu, Nov 30, 2017 at 7:39 PM, Luis R. Rodriguez <mcgrof@kernel.org> 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.

Hm? I'm confused by what you mean here. The patchset just saves andprints a module's aliases on module load if the debug option isenabled. There's no dependency tracking here; that's modprobe's job.And if you need to see which additional modules are being loaded as aresult of a module load there's already modprobe --verbose andmodules.dep..

>> 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 ?

Ditto, I agree that a concrete debugging example would be helpful inunderstanding why having this in-kernel is better than using existinguserspace tools to look up module aliases. AFAIK the debug prints onlyon module load, but you could also easily get the aliases for allmodules loaded on your system by doing something like -