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." _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
