On 2024-07-26 10:54, Qiang Yu wrote:
On Fri, Jul 26, 2024 at 4:03 PM Dragan Simic <dsimic@xxxxxxxxxxx>
wrote:
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@xxxxxxxxxxx/
Yeah, I've seen that mail. But I haven't seen clearly how weakdep will
change
in the future which could break our usage here. As an interface exposed
to other
users, I expect it should be stable.
Let me clarify, please.
The intent isn't to prevent breakage, but to future-proof our weakdeps
that are actually harddeps under the hood. Of course, weakdeps aren't
expected to become unsuitable for our needs in the future, but we might
actually need to treat our uses of weakdeps as harddeps at some point,
so marking them as (currently aliased) harddeps leaves clear "earmarks"
for us in the future.
The Btrfs example, which I used in my earlier response on linux-modules,
shows how such "earmarks" can be useful after some time passes.
> On Thu, Jul 25, 2024 at 4:21 PM Dragan Simic <dsimic@xxxxxxxxxxx>
> 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@xxxxxxxxxxx>
>> >> 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@xxxxxxxxxx/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
