[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] grub_video_fbrender_target
From: |
Robert Millan |
Subject: |
Re: [PATCH] grub_video_fbrender_target |
Date: |
Mon, 23 Nov 2009 10:27:19 +0100 |
User-agent: |
Mutt/1.5.18 (2008-05-17) |
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."