[lkml]   [2017]   [Dec]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: module: add debugging alias parsing support
On Mon, Dec 4, 2017 at 2:58 PM, Jessica Yu <> wrote:
> +++ Djalal Harouni [04/12/17 10:01 +0100]:
>> On Thu, Nov 30, 2017 at 7:39 PM, Luis R. Rodriguez <>
>> 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 and
> prints a module's aliases on module load if the debug option is
> enabled. There's no dependency tracking here; that's modprobe's job.
> And if you need to see which additional modules are being loaded as a
> result of a module load there's already modprobe --verbose and
> modules.dep..

Yes I was referring by the printing or kernel logs order, if two
modules depend on same one, we know which first one triggered it, and
in that context it will be a bit easier in the auto-loading context,
maybe like crypto ones that can be triggered from anywhere.



 \ /
  Last update: 2017-12-04 15:18    [W:0.045 / U:0.480 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site