On Fri, Jul 26, 2024 at 4:03 PM Dragan Simic <dsimic@xxxxxxxxxxx> wrote: > > 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@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. > > 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
