Hi Timur, On 11/17/2011 08:19 PM, Timur Tabi wrote: > Timur Tabi wrote: >> Introduce functions framebuffer_init() and framebuffer_cleanup() to allow >> the initialization of a user-allocated fb_info object. >> >> framebuffer_alloc() allows for appending a private data structure when it >> allocates the fb_info object. However, a driver that registers multiple >> framebuffers for one device may also need another private data structure >> for the device itself. framebuffer_init() allows such drivers to store >> the fb_info objects in the device-specific private data structure, >> thereby simplifying memory allocation. >> >> Signed-off-by: Timur Tabi <timur@xxxxxxxxxxxxx> > > Florian, > > Any comments on this patch? If you're okay with the change, I want to take > advantage of it in my framebuffer driver. Of course you want, otherwise I'd be wondering why you are sending this patch at all. But I don't see any advantages of your approach. Instead of pointers to fb_info with this patch you could embed fb_info directly in your data structure but that is barely a difference for a programmer I'd think. You'd still have to call your new functions on init/exit so the amount of function calls needed is the same with or without the patch (I could see an advantage if alloc and release were pure memory allocations). Or is this all about handling the case when fb_alloc fails? Historically some drivers don't even call alloc but have their own fb_info and call only register. I do not want to add yet another way of doing framebuffer initialization unless you can clearly show its benefits. Best regards, Florian Tobias Schandinat -- 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
