On Tue, Apr 12, 2022 at 12:14:32PM -0300, Bruno Moreira-Guedes wrote: > On Sun, Apr 03, 2022 at 01:05:44PM +0200, Greg Kroah-Hartman wrote: > > > >On Fri, Apr 01, 2022 at 03:21:50PM -0300, Bruno wrote: > >> With my tests in my, I have found two other things that I think are > >> remarkable to mention. First one is a missing `depends on` line for > >> `VME_BRIDGE` in drivers/staging/vme/devices/Kconfig, not visible > >> because they were in the same tree, but now unveiled. I'm fixing it, > >> do you think it's best to add it in the same patch? > > > > Make that a second patch, and resend it as part of a patch series since > > your first patch here is gone from my queue. > > This patch is already sent, so I'll trim most of this message to avoid > duplicating the discussions. There's only one thing I'd like some input > first, if you don't mind. > > >> Do you think it would be interesting for a future patch to provide > >> some output when drivers from the staging tree are present in the > >> running kernel image? > > > > If you can figure out how to do so, that would be interesting to see. > I think I might have figured out. In "include/modules.h" and > "include/init.h" I happened to notice the driver initialization is > handled by some macros. After some inspection through gcc -E and looking > how they are defined, I figured out a scenario (when MODULE is not > defined) where the module_init() macro is defined as (among other > things) an inline initcall function that wraps the driver initialization > function. > > So I thought about implementing it by creating a -DSTAGING flag in > drivers/staging/Makefile, and then using this macro to make an #ifdef > STAGING to add a similar inline wrapping function, except that in this > case the function makes a pr_warning() before calling the initialization > function. > > Do you think it would be a good way of solving that? Yes, that would be a possible way, try it and see! greg k-h
