Re: Fwd: [PATCH 1/2] Framebuffer split

[Vladimir 'phcoder' Serbinenko]

>> >> +#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
> address@hidden
> http://lists.gnu.org/mailman/listinfo/grub-devel
>



-- 
Regards
Vladimir 'phcoder' Serbinenko

Personal git repository: http://repo.or.cz/w/grub2/phcoder.git