Date: Tue, 19 Feb 2008 12:27:06 -0800 From: Marcel Moolenaar <xcllnt@mac.com> To: Oliver Fromme <olli@lurza.secnetix.de> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: /boot/loader graphics support & extensibility Message-ID: <D31D9C9E-3473-4AC1-8C1D-94C0FE68BDC8@mac.com> In-Reply-To: <200802191943.m1JJhdrJ044356@lurza.secnetix.de> References: <200802191943.m1JJhdrJ044356@lurza.secnetix.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Feb 19, 2008, at 11:43 AM, Oliver Fromme wrote:
> It will not replace the current text menu ("beastie.4th"),
> so you can still use it on your Hercules monochrome or CGA
> machine or with serial console, of course.
We can probably forget about those configurations.
> This is a list of things that comes to mind:
>
> (a) Support for i386/amd64 machines that have VGA hard-
> ware but no VGA BIOS (this is different from the
> system BIOS!). Is there a sufficiently large number
> of such systems that it would be desirable to support
> them?
Yes, see (b).
> (b) Support for non-i386/amd64 machines that have VGA
> hardware (ia64, powerpc, ...).
Yes, see (a).
> (c) Support for non-VGA graphics hardware (any platform).
Think sparc64, here. Abstraction of the hardware should be
enough to make it easy for someone with the specs in hand
and the hardware on the shelf.
> Personally I won't be able to implement any of the above
> because I only have standard i386/amd64 hardware. But
> if someone else wants to implement it, my code certainly
> shouldn't get in the way.
I agree.
> Currently my code is simply compiled conditionally,
> depending on make(1) variables (${MACHINE_ARCH}), so it
> is only included for i386 and amd64.
>
> So, basically, if multiple platforms are supported, the
> source file with the graphics support functions would be
> selected based on ${MACHINE_ARCH}.
>
> Would that be sufficient? I have looked at the archsw,
> but I'm not sure if that gives any additional benefit
> in this case. For a different architecture you ahve to
> compile a different binary anyway, so it seems that it
> is sufficient to make the decision at build time, so the
> additional indirection of the archsw isn't required.
> Please someone correct me if I'm wrong.
True; the archsw is mostly bogus. We can simply call, say,
arch_copyin(), rather than do it indirectly with
archsw.arch_copyin(). So, there's no need to go through
archsw per-se. The point is mostly one of abstracting the
hardware using the right "call-back" functions.
> Comments appreciated.
I love the screenshot. I'm going to use the background in
my VTY driver as well :-)
--
Marcel Moolenaar
xcllnt@mac.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?D31D9C9E-3473-4AC1-8C1D-94C0FE68BDC8>