Hi On Sun, Jun 17, 2012 at 12:04 AM, David Herrmann <dh.herrmann@xxxxxxxxxxxxxx> 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 indices. 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. Regards David -- To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
