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

[Robert Millan <rmh@aybabtu.com>]

On Sat, Aug 01, 2009 at 05:10:30PM +0200, Vladimir 'phcoder' Serbinenko wrote:
> > Btw, if I understand correctly, we have a race condition right now.  As a
> > bugfix it'd be better to merge this separately from the interface redesign if
> > possible.
> race condition? We don't even have threads

Well, we have the possibility that video drivers are doing stuff in background,
but that's something entirely different I had in mind.  Please bear with me, I
missunderstood what you wrote :-)

> > Why is this chunk of code moved down?  AFAICS, this change only involves
> > adding an additional layer between it and the video backend.  Does this
> > make it conflict with something else?
> >
> I wanted to keep normal grub_printf as long as possible and after
> get_mode_and_fini grub_printf may be unfunctional.

Ok

> >> +#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?

-- 
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."