[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.026 / U:33.756 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site