Re: [PATCH] fb: split out framebuffer initialization from allocation

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