public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Steven Price <steven.price@arm.com>
To: Lucas De Marchi <lucas.demarchi@intel.com>,
	Dragan Simic <dsimic@manjaro.org>
Cc: linux-modules@vger.kernel.org, mcgrof@kernel.org,
	linux-kernel@vger.kernel.org, didi.debian@cknow.org,
	Boris Brezillon <boris.brezillon@collabora.com>,
	Qiang Yu <yuq825@gmail.com>
Subject: Re: [PATCH] module: Add hard dependencies as syntactic sugar
Date: Thu, 25 Jul 2024 16:39:40 +0100	[thread overview]
Message-ID: <1393cce9-bd64-469d-aa2b-0fb768bf9e87@arm.com> (raw)
In-Reply-To: <gcykzencr7rmeiy3rmclxrbbvuryo2uyb6plqqovee3bsme42b@g6pwzbgitgka>

On 25/07/2024 15:29, Lucas De Marchi wrote:
> On Thu, Jul 25, 2024 at 01:37:46PM GMT, Dragan Simic wrote:
>> Panfrost and Lima DRM drivers use devfreq to perform DVFS, which is
>> supported
>> on the associated platforms, while using simple_ondemand devfreq
>> governor by
>> default.  This makes the simple_ondemand module a hard dependency for
>> both
>> Panfrost and Lima, because the presence of the simple_ondemand module
>> in an
>> initial ramdisk allows the initialization of Panfrost or Lima to succeed.
>> This is currently expressed using MODULE_SOFTDEP. [1][2]  Please see
>> commits
>> 80f4e62730a9 ("drm/panfrost: Mark simple_ondemand governor as
>> softdep") and
>> 0c94f58cef31 ("drm/lima: Mark simple_ondemand governor as softdep") for
>> additional background information.
>>
>> With the addition of MODULE_WEAKDEP in commit 61842868de13 ("module:
>> create
>> weak dependecies"), the dependency between Panfrost/Lima and
>> simple_ondemand
>> can be expressed in a much better way as a weakdep, because that provides
>> the required dependency information to the utilities that generate
>> initial
>> ramdisks, but leaves the actual loading of the required kernel
>> module(s) to
>> the kernel.  However, being able to actually express this as a hard
>> module
>> dependency would still be beneficial.
>>
>> With all this in mind, let's add MODULE_HARDDEP as some kind of syntactic
> 
> Sorry, but NACK from me. This only adds to the confusion.
> 
> hard/normal dependency:
>     It's a symbol dependency. If you want it in your module, you
>     have to use a symbol. Example:
> 
>     $ modinfo ksmbd | grep depends
>     depends:        ib_core,rdma_cm,nls_ucs2_utils,cifs_arc4
> 
> 
> soft dependency:
>     A dependency you declare in configuration or in the module
>     info added by the kernel. A "pre" softdep means libkmod/modprobe
>     will try to load that dep before the actual module. Example:
> 
>     $ modinfo ksmbd | grep softdep
>     softdep:        pre: crc32
>     softdep:        pre: gcm
>     softdep:        pre: ccm
>     softdep:        pre: aead2
>     softdep:        pre: sha512
>     softdep:        pre: sha256
>     softdep:        pre: cmac
>     softdep:        pre: aes
>     softdep:        pre: nls
>     softdep:        pre: md5
>     softdep:        pre: hmac
>     softdep:        pre: ecb
> 
> weak dependency:
>     A dependency you declare in configuration or in the module
>     info added by the kernel. libkmod/modprobe will not change the
>     way it loads the module and it will only used by tools that need
>     to make sure the module is there when the kernel does a
>     request_module() or somehow tries to load that module.
> 
> So if you want a hard dependency, just use a symbol from the module. If
> you want to emulate a hard dependency without calling a symbol, you use
> a pre softdep, not a weakdep.  You use a weakdep if the kernel itself,
> somehow may load module in runtime.
> 
> The problem described in 80f4e62730a9 ("drm/panfrost: Mark
> simple_ondemand governor as softdep")
> could indeed be solved with a weakdep, so I'm not sure why you'd want to
> alias it as a "hard dep".

The simple_ondemand dependency sadly isn't visible as a symbol. It's
currently 'fixed' by using a softdep, but that has drawbacks and doesn't
actually express the requirement. A "weakdep" works, but has the
drawback that it implies that the dependency is optional. This patch at
least means that the driver can express the dependency, even if
currently that just gets output as the same weakdep.

I'm not sure what the logic was behind the name "weak" - what we
(currently at least) have in panfrost is not a weak dependency by the
normal definition of the term - the driver will fail to load if the
ondemand governor is unavailable.

This patch doesn't solve the confusion, but at least means panfrost
doesn't need another round of churn in the future. The alternative
presumably is don't merge this and panfrost will have to wait until a
proper "hard dependency" mechanism is available.

Steve


  parent reply	other threads:[~2024-07-25 15:39 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-25 11:37 [PATCH] module: Add hard dependencies as syntactic sugar Dragan Simic
2024-07-25 13:14 ` Steven Price
2024-07-25 14:29 ` Lucas De Marchi
2024-07-25 15:39   ` Dragan Simic
2024-07-25 15:39   ` Steven Price [this message]
2024-07-25 17:18     ` Lucas De Marchi
2024-07-25 19:32       ` Dragan Simic

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=1393cce9-bd64-469d-aa2b-0fb768bf9e87@arm.com \
    --to=steven.price@arm.com \
    --cc=boris.brezillon@collabora.com \
    --cc=didi.debian@cknow.org \
    --cc=dsimic@manjaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-modules@vger.kernel.org \
    --cc=lucas.demarchi@intel.com \
    --cc=mcgrof@kernel.org \
    --cc=yuq825@gmail.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox