lkml.org 
[lkml]   [2006]   [Jul]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [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:
    >> >> 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 code looks ok but this sure smells like inter_module_*.

    I assure you, there is no smell of inter_module_* here. What scenario
    are you afraid of?

    > I guess
    > inter_module had to deal with arbitrary users and this code is dealing
    > with a fixed set of clients which makes it more manageable.
    >
    > Have you considered making this a generic service and not fb specific?
    >

    It's basically a wrapper to the notifier_call_chain, that's as generic
    as it can get. And yes, it's not fb_specific (meaning, there's no need
    for the client module to know fbdev internals), that's why the lcd and
    backlight subsystem can take advantage of it.

    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/

    \
     
     \ /
      Last update: 2006-07-11 16:53    [W:7.263 / U:0.000 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site