>> >> +#define grub_video_render_target grub_video_fbrender_target >> > >> > If we want to rename this function, I'd rather do it all the way than >> > keeping a compatibility macro. But then, I'd also prefer if this is >> > done separately from the rest (either before or after). >> > >> It's not about renaming but to inform includes that >> grub_video_render_target is in fact grub_video_fbrender_target and so >> avoid warnings and casts. > > I don't understand this. If we want to settle with grub_video_render_target > why don't we just provide that function directly? Or is this making room > for an additional layer later on?
It's for abstraction we already have. Most of video subsystem doesn't care whether render_target is framebuffer, OpenGL or network commands. In this particular case we know that we're rendering to a framebuffer and so function do_something (grub_video_render_target *my_render_target); like it's used by upper layers is inded the same as do_something (grub_video_fbrender_target *my_render_target); and not e.g. do_something (grub_video_glrender_target *my_render_target); > > -- > 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 > Grub-devel@gnu.org > http://lists.gnu.org/mailman/listinfo/grub-devel > -- Regards Vladimir 'phcoder' Serbinenko Personal git repository: http://repo.or.cz/w/grub2/phcoder.git _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
