public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Dragan Simic <dsimic@manjaro.org>
To: Qiang Yu <yuq825@gmail.com>
Cc: Maxime Ripard <mripard@kernel.org>,
	dri-devel@lists.freedesktop.org, lima@lists.freedesktop.org,
	maarten.lankhorst@linux.intel.com, tzimmermann@suse.de,
	airlied@gmail.com, daniel@ffwll.ch, linux-kernel@vger.kernel.org,
	Philip Muller <philm@manjaro.org>,
	Oliver Smith <ollieparanoid@postmarketos.org>,
	Daniel Smith <danct12@disroot.org>,
	stable@vger.kernel.org
Subject: Re: [PATCH] drm/lima: Mark simple_ondemand governor as softdep
Date: Fri, 26 Jul 2024 10:03:45 +0200	[thread overview]
Message-ID: <7d1c35d6829f00fa62ea39b6fee656be@manjaro.org> (raw)
In-Reply-To: <CAKGbVbucXy+5Sn9U55DY69Lw9bQ+emmN1G4L8DQcUC1wdFSP_Q@mail.gmail.com>

Hello Qiang Yu,

On 2024-07-26 08:07, Qiang Yu wrote:
> Yeah, I agree weakdep is a better choice here. It solves the confusion
> of softdep which the depend module is optional.

Thanks, I'm glad that you agree.

> But I prefer using weakdep directly instead of creating an aliasing of
> it which has no actual difference.

Just checking, did you have a chance to read what I wrote in my earlier
response on the linux-modules mailing list, [7] which includes a rather
elaborate explanation of the intent behind MODULE_HARDDEP being 
currently
just a proposed alias for MODULE_WEAKDEP?  It also describes why using
this alias might save use some time and effort in the future.

[7] 
https://lore.kernel.org/linux-modules/0720a516416a92a8f683053d37ee9481@manjaro.org/

> On Thu, Jul 25, 2024 at 4:21 PM Dragan Simic <dsimic@manjaro.org> 
> wrote:
>> 
>> Hello Qiang,
>> 
>> On 2024-06-26 08:49, Dragan Simic wrote:
>> > On 2024-06-26 03:11, Qiang Yu wrote:
>> >> On Wed, Jun 26, 2024 at 2:15 AM Dragan Simic <dsimic@manjaro.org>
>> >> wrote:
>> >>> Just checking, any further thoughts about this patch?
>> >>>
>> >> I'm OK with this as a temp workaround because it's simple and do no
>> >> harm
>> >> even it's not perfect. If no other better suggestion for short term,
>> >> I'll submit
>> >> this at weekend.
>> >
>> > Thanks.  Just as you described it, it's far from perfect, but it's
>> > still
>> > fine until there's a better solution, such as harddeps.  I'll continue
>> > my
>> > research about the possibility for adding harddeps, which would
>> > hopefully
>> > replace quite a few instances of the softdep (ab)use.
>> 
>> Another option has become available for expressing additional module
>> dependencies, weakdeps. [1][2]  Long story short, weakdeps are similar
>> to softdeps, in the sense of telling the initial ramdisk utilities to
>> include additional kernel modules, but weakdeps result in no module
>> loading being performed by userspace.
>> 
>> Maybe "weak" isn't the best possible word choice (arguably, "soft" 
>> also
>> wasn't the best word choice), but weakdeps should be a better choice 
>> for
>> use with Lima and governor_simpleondemand, because weakdeps provide 
>> the
>> required information to the utilities used to generate initial 
>> ramdisk,
>> while the actual module loading is left to the kernel.
>> 
>> The recent addition of weakdeps renders the previously mentioned
>> harddeps
>> obsolete, because weakdeps actually do what we need.  Obviously, 
>> "weak"
>> doesn't go along very well with the actual nature of the dependency
>> between
>> Lima and governor_simpleondemand, but it's pretty much just the 
>> somewhat
>> unfortunate word choice.
>> 
>> The support for weakdeps has been already added to the kmod [3][4] and
>> Dracut [5] userspace utilities.  I'll hopefully add support for 
>> weakdeps
>> to mkinitcpio [6] rather soon.
>> 
>> Maybe we could actually add MODULE_HARDDEP() as some kind of syntactic
>> sugar, which would currently be an alias for MODULE_WEAKDEP(), so the
>> actual hard module dependencies could be expressed properly, and
>> possibly
>> handled differently in the future, with no need to go back and track 
>> all
>> such instances of hard module dependencies.
>> 
>> With all this in mind, here's what I'm going to do:
>> 
>> 1) Submit a patch that adds MODULE_HARDDEP() as syntactic sugar
>> 2) Implement support for weakdeps in Arch Linux's mkinitcpio [6]
>> 3) Depending on what kind of feedback the MODULE_HARDDEP() patch
>> receives,
>>     I'll submit follow-up patches for Lima and Panfrost, which will 
>> swap
>>     uses of MODULE_SOFTDEP() with MODULE_HARDDEP() or MODULE_WEAKDEP()
>> 
>> Looking forward to your thoughts.
>> 
>> [1] 
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/include/linux/module.h?id=61842868de13aa7fd7391c626e889f4d6f1450bf
>> [2] 
>> https://lore.kernel.org/linux-kernel/20240724102349.430078-1-jtornosm@redhat.com/T/#u
>> [3] 
>> https://github.com/kmod-project/kmod/commit/05828b4a6e9327a63ef94df544a042b5e9ce4fe7
>> [4] 
>> https://github.com/kmod-project/kmod/commit/d06712b51404061eef92cb275b8303814fca86ec
>> [5] 
>> https://github.com/dracut-ng/dracut-ng/commit/8517a6be5e20f4a6d87e55fce35ee3e29e2a1150
>> [6] https://gitlab.archlinux.org/archlinux/mkinitcpio/mkinitcpio

  reply	other threads:[~2024-07-26  8:03 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-17 20:22 [PATCH] drm/lima: Mark simple_ondemand governor as softdep Dragan Simic
2024-06-18  4:33 ` Qiang Yu
2024-06-18  8:01   ` Qiang Yu
2024-06-18  8:13     ` Maxime Ripard
2024-06-18 10:33       ` Dragan Simic
2024-06-18 19:22         ` Dragan Simic
2024-06-25 18:15           ` Dragan Simic
2024-06-26  1:11             ` Qiang Yu
2024-06-26  6:49               ` Dragan Simic
2024-06-30 10:04                 ` Qiang Yu
2024-07-25  8:21                 ` Dragan Simic
2024-07-26  6:07                   ` Qiang Yu
2024-07-26  8:03                     ` Dragan Simic [this message]
2024-07-26  8:54                       ` Qiang Yu
2024-07-26  9:25                         ` 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=7d1c35d6829f00fa62ea39b6fee656be@manjaro.org \
    --to=dsimic@manjaro.org \
    --cc=airlied@gmail.com \
    --cc=danct12@disroot.org \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=lima@lists.freedesktop.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=mripard@kernel.org \
    --cc=ollieparanoid@postmarketos.org \
    --cc=philm@manjaro.org \
    --cc=stable@vger.kernel.org \
    --cc=tzimmermann@suse.de \
    --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