[lkml]   [2012]   [Jun]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC 00/10] fblog: framebuffer kernel log driver

On Sun, Jun 17, 2012 at 12:04 AM, David Herrmann
<> wrote:
> Hi
> As some might know I am working on making CONFIG_VT obsolete. But as a developer
> it is often useful to have a kernel-log on the screen during boot to debug many
> common kernel(-config) errors. However, without CONFIG_VT we cannot use the
> VGA/framebbufer consoles either. Therefore, I am working on a small driver
> called "fblog".
> This driver simply writes the kernel log to all connected framebuffers. It works
> similar to fbcon but removes all the complexity of the virtual terminals. There
> is a sysfs attribute called "active" that allows to enable/disable fblog so
> user-space can start an xserver or similar.
> The main purpose is debugging kernel boot problems. Therefore, it is not
> optimized for speed and I tried keeping it simple. I splitted the patches
> into 10 small chunks to make review easier.
> I would be glad if someone could review this and tell me whether this is
> something we could include in mainline or not.
> There are still some issues but apart from them it works fine on my
> machine (x86):
>  - I register the fblog device during module_init and need to call
>    module_get(). However, this means it is impossible to call "rmmod fblog" as
>    fblog has a reference to itself. Using "rmmod -f fblog" works fine but is a
>    bit ugly. Is there a nice way to fix this? Otherwise I would need to call
>    device_get() in module_exit() if there is a pending user of the fblog-device
>    even though I unregistered it.
>  - I redraw all framebuffers while holding the console-lock. This may slow down
>    machines with more than 2 framebuffers (like 10 or 20). However, as this is
>    supposed to be a debug driver, I think I can ignore this? If someone wants
>    to improve the redraw logic to avoid redrawing the whole screen all the
>    time, I would be glad to include it in this patchset :)
>  - I am really no expert regarding the framebuffer subsystem. So I would
>    appreciate it if someone could comment whether I need to handle the events
>    in a different way or whether it is ok the way it is now.

One additional issue:
With udlfb.c we have hotplug capable framebuffers. However, fbcon and
fblog currently never close a framebuffer if not explicitely requested
by user-space. Therefore, if a framebuffer device is removed, the
FB_EVENT_FB_UNREGISTER event will never be sent because fbcon/fblog
still have a reference to the framebuffer(-driver). Therefore, the
number of available fbs will grow until there are no more free

See dlfb_usb_disconnect() in udlfb.c for an example. It does not
invoke unregister_framebuffer() unless the last user closed the FB.
udlfb disables the console on its framebuffer devices to avoid this,
but this doesn't seem to be a good solution.
How about sending an FB_EVENT_FB_DISCONNECT event during unlink_framebuffer()?

This still doesn't force user-space to close /dev/fbX but it at least
will make it possible to fblog/fbcon to close the framebuffer. fbmem.c
can then still be modified to mark the open file as dead so user-space
will also close the device hopefully.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2012-06-18 21:41    [W:0.070 / U:2.504 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site