All of lore.kernel.org
 help / color / mirror / Atom feed
From: Adrian Ratiu <adrian.ratiu@collabora.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	kernel@collabora.com, linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH 0/1] Initialize debugfs/ksysfs earlier?
Date: Thu, 03 Jun 2021 23:00:00 +0300	[thread overview]
Message-ID: <87y2bqwwfz.fsf@collabora.com> (raw)
In-Reply-To: <YLjVYaVfNGEkqPAQ@kroah.com>

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

  reply	other threads:[~2021-06-03 20:00 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-03 12:55 [RFC PATCH 0/1] Initialize debugfs/ksysfs earlier? Adrian Ratiu
2021-06-03 12:55 ` [RFC PATCH 1/1] drivers: base: Expose probe failures via debugfs Adrian Ratiu
2021-06-03 13:16   ` Greg Kroah-Hartman
2021-06-03 20:00     ` Adrian Ratiu
2021-06-04 12:58       ` Greg Kroah-Hartman
2021-06-03 13:13 ` [RFC PATCH 0/1] Initialize debugfs/ksysfs earlier? Greg Kroah-Hartman
2021-06-03 20:00   ` Adrian Ratiu [this message]
2021-06-04 12:56     ` Greg Kroah-Hartman
2021-06-04 16:06       ` Adrian Ratiu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87y2bqwwfz.fsf@collabora.com \
    --to=adrian.ratiu@collabora.com \
    --cc=akpm@linux-foundation.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=kernel@collabora.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rafael@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.