lkml.org 
[lkml]   [2021]   [Jun]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [RFC PATCH 0/1] Initialize debugfs/ksysfs earlier?
Date
Hi and thank you for the quick response!

On Thu, 03 Jun 2021, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
> On Thu, Jun 03, 2021 at 03:55:33PM +0300, Adrian Ratiu wrote:
>> Hi Greg & all, I would like to add a new debugfs file like in
>> the next patch but I'm having a problem with commit
>> 56348560d495 ("debugfs: do not attempt to create a new file
>> before the filesystem is initalized").
>
> You should have had a problem before that commit happened as
> well, right?
>

Actually no, it works without problems before commit 56348560d495
and also works if I revert that commit or move the debugfs_init()
and its dependency ksysfs_init() before the driver core init.

All these 3 cases work without issues while testing, but none of
them seem to be viable ideas and especially moving debugfs init
earlier just to add this new attr file to the driver core is some
thin reasoning, so that's why I asked via this RFC. :)

>> The problem is debugfs is initialized after the driver core,
>> during the core initcall, so I get an -ENOENT failure due to
>> the above commit. My first reaction is to move the
>> ksysfs_init() and debugfs_init() calls before the driver core
>> init which works. Would that be ok? An alternative would be
>> to create the new debugfs file somewhere else than the driver
>> core, but I'm not sure where would be a good location, maybe in
>> debugfs_init()? Doesn't seem right.
>
> I don't really want the driver core to be messing with debugfs
> at all, why is that needed? I'll respond on your patch...

KernelCI maintainers asked me to add some tests for driver probe()
results similar to how the -EPROBE_DEFER is tested via the
existing debugfs devices_deferred and at the same time to add a
new debugfs interface similar to devices_deferred to avoid parsing
the printk buffer for non-EPROBE_DEFER results.

If you think adding such an interface is a bad idea, please just
tell me so and I will use it as amunition to push back and get the
info from printk. :)

>
> thanks,
>
> greg k-h

\
 
 \ /
  Last update: 2021-06-03 22:00    [W:1.074 / U:0.152 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site