>I see four options here:
>
>1) design graphics drivers interface and register it when loading
>module. Pros is that it is easy to write new graphics drivers. Cons is
>that we need to have then virtual screen support (not hard to make).
>
>
>
Perhaps the best way
>2) improve terminal interface. Cons for this are that terminal interface
>can grow quite large
>
>and not all functions are relevant to terminal.
>
>
Ir would be possible to add the terminal flag TERM_VIDEO_CAPABLE and
also write video part of module between #ifdef WITH_VIDEO and so compile
twice:
with video and without. Cons: last control for terminal rendering is on the
terminal driver, so even if they use some common functions like font
rendering there is
a risk that the terminals will be different with different video driver -
bad thing and in this way we must also have virtual screen support
>3) implement some generic code in kernel level. Pros is that it is
>easier to interface with it.
>
Why?
>Cons are that kernel size increases.
>
>4) design some helper function interface that could be used to make
>dynamic function calls to module code. Cons are 'What happens then when
>module is unloaded?'.
>
>Perhaps there are other options ?
>
>
>
We could do like terminal support, but separate
>Thanks,
>Vesa Jääskeläinen
>
>
>
>
Vladimir
_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
