On Sun, Nov 22, 2009 at 02:01:00PM +0100, Vladimir 'φ-coder/phcoder' Serbinenko wrote: > Robert Millan wrote: > > According to its description, struct grub_video_fbrender_target is a > > driver-specific structure. video_fb.c is generic code and shouldn't be > > using this struct to define its function calls, as this makes it impossible > > to use any of them from outside a driver. > > > > > grub_video_render_target is driver-specific but > grub_video_fbrender_target isn't. Host driver can either put > #define grub_video_render_target grub_video_fbrender_target > In which case driver effectively adopts fbrender_target as its > render_target or add encapsulators for video_fb functions. I think this > patch does more harm than good since if grub_video_render_target isn't > grub_video_fbrender_target then compiler won't complain.
Ah, I see what you mean. This is unfortunate, as drivers can't be offloaded from the obligation to define generic handlers just to assert that they use the same struct definition. I was trying to simplify driver registration by making it optional to define operations, making the fallback to generic code automatic. But well, it's not so important. -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all." _______________________________________________ Grub-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/grub-devel
