Bruno Prémont wrote: > Wouldn't it even make sense to move some more of the initialization of fb_info > out of fb registration into this new init funtion? (I'm thinking about initializing > mutexes and the like) I was thinking the opposite. See my reply to Florian's message. > This way fb_info could be used before being registered. Registration would then > be reduced to makeing the framebuffer visible to userspace and listed in > registered_fb[]. > > This way framebuffer_alloc() would be no more that kzalloc(), framebuffer_init() > would setup all "non-zero" fields of fb_info (including setup of all mutexes, one > of which is currently being done by framebuffer_alloc() and the rest by > do_register_framebuffer()!). I think the problem is that it's unclear what the difference is between framebuffer_alloc() and register_framebuffer(). The problem is that register_framebuffer() also initializes the fb_info structure. So some initialization is done in framebuffer_alloc(), some is done in register_framebuffer(), and some is done by the driver. Not only that, but drivers that don't call framebuffer_alloc() can't really know what needs to be initialized before calling register_framebuffer(). Why is fb_info->lock initialized in register_framebuffer(), but fb_info->bl_curve_mutex is initialized in framebuffer_alloc()? They're both mutexes. -- Timur Tabi Linux kernel developer at Freescale -- 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
