Hi
I do not know, whether this can be a problem for any existing driver, but
such an inconsistency seems like a bad idea to me anyway. The struct
fb_ops::fb_release() method can be called in following ways:
fbmem.c::fb_release() under the info->lock mutex (file.close("/dev/fbX")
operation)
fbcon.c::con2fb_release_oldinfo() under console semaphore
fbcon.c::fbcon_exit() from
fbcon_deinit() from
vt.c::vc_deallocate() under console semaphore (has
WARN_CONSOLE_UNLOCKED())
bind_con_driver() under console semaphore
fb_console_exit() under console semaphore
I.e., it can be either called within an acquire_console_sem() /
release_console_sem() block, or within a mutex_lock(&info->lock) /
mutex_unlock(&info->lock) block, which looks inconsistent to me.
The problem, this is causing me is, that I'd like to call the framebuffer
notifier chain from my driver's fb_release() method. That chain has to be
called under a console semaphore. So, I either have to rely on the caller
holding the semaphore, or take it myself, none of which is possible due to
the above inconsistency. Same holds for the info->lock mutex - you cannot
rely on it being help and you cannot take it yourself... I believe, the
same holds for fb_ops::fb_open(). Is this a featuer or a bug? If the
latter - how best to fix it? If the former - how do I solve my problem?
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
