Messages in this thread | | | Date | Tue, 11 Jul 2006 22:34:21 +0800 | From | "Antonino A. Daplas" <> | Subject | Re: [PATCH] fbdev: Statically link the framebuffer notification functions |
| |
Jon Smirl wrote: > On 7/11/06, Antonino A. Daplas <adaplas@gmail.com> wrote: >> Jon Smirl wrote: >> > On 7/11/06, Antonino A. Daplas <adaplas@gmail.com> wrote: >> >> The backlight and lcd subsystems can be notified by the framebuffer >> layer >> >> of blanking events. However, these subsystems, as a whole, can >> function >> >> independently from the framebuffer layer. But in order to enable to >> >> the lcd and backlight subsystems, the framebuffer has to be compiled >> >> also, >> >> effectively sucking in a huge amount of unneeded code. Besides, the >> >> dependency >> >> is introducing a lot of compilation problems. >> > >> > This code is effectively rebuilding a fb specific version of >> > inter_module_get/put., something that was removed earlier. >> >> Huh? I don't see any semblance of inter_module_* or symbol_* in there. >> Read the patch again. > > You are providing a fixed point to do a rendezvous between modules > without refcount tracking. That's what inter_module did.
No, you're confused on inter_module. inter_module_* allows 2 or more modules to share data. The danger is that one module may disappear while the other is still accessing the data.
In this case, there is absolutely no data sharing. One module can safely unload without affecting the other. The only danger is that one might be in a midst of a calling the callout function while the other is unregistering its notifier block. But then the notifier chain already protects this from happening.
> The symbol is > being passed implicitly via the entry point names. > > Just wrap fb_notifier in a module and it will get tracked.
No, there's no need to do this. It just adds more complexity to the already complicated dependency.
Tony - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |