Re: [PATCH v4 2/3] driver core: make software nodes available earlier

[Bartosz Golaszewski]

On Tue, Mar 31, 2026 at 10:55 AM Andy Shevchenko
<andriy.shevchenko@xxxxxxxxxxxxxxx> wrote:
>
> On Mon, Mar 30, 2026 at 11:52:34PM -0700, Dmitry Torokhov wrote:
> > On March 30, 2026 11:25:33 PM PDT, Andy Shevchenko <andriy.shevchenko@xxxxxxxxxxxxxxx> wrote:
> > >On Mon, Mar 30, 2026 at 02:46:45PM -0700, Dmitry Torokhov wrote:
> > >> On Mon, Mar 30, 2026 at 11:24:45PM +0300, Andy Shevchenko wrote:
> > >> > On Mon, Mar 30, 2026 at 02:40:47PM +0200, Bartosz Golaszewski wrote:
>
> ...
>
> > >> > > -static void __exit software_node_exit(void)
> > >> > > -{
> > >> > > -      ida_destroy(&swnode_root_ids);
> > >> > > -      kset_unregister(swnode_kset);
> > >> > >  }
> > >> > > -__exitcall(software_node_exit);
> > >> >
> > >> > Why? What's wrong with the __exitcall?
> > >>
> > >> It's dead code. Always was, always will be.
> > >>
> > >> Maybe split in a separate patch, but I sometimes feel the idea of "one
> > >> change" is taken to extreme and adds to both developer's and maintainers
> > >> burden by needing to keep track of extra patches.
> > >
> > >Why does __exitcall() exist then? It's also used in other places.
> > >I think it's generally good to have a possibility to clean up
> > >after run.
> >
> > The code section will be discarded when the kernel finishes booting so it
> > only increases image size on disk.
>
> Almost true. Interesting microblaze case, where it's not discarded.
> But I can't find where it's actually used on any architecture.
>
> > >A bit of archaeology:
> > >
> > >The first time it appeared was in the bcc2152647b8 ("Import 2.4.0-test3pre3").
> > >Then somehow spread a bit (but not much).
> >
> > And it shows how useful it is. Maybe it had some purpose a long time ago, but
> > at present time this code will never be executed since it cannot be built as
> > a module.
>
> Are you sure about definition of __exitcall? As I read init.h the macro
> is defined when it's not a MODULE.
>
> Anyways, if we going to drop that, it should be in a separate change
> explaining all these.
>

Sure. We must drop it too because the initialization no longer happens
in an initcall but is called from elsewhere so - were it not dead code
- we could end up with it being called before the init function.

Bart