From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 19 20:38:13 2008 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 077CC16A418 for ; Tue, 19 Feb 2008 20:38:13 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from smtpoutm.mac.com (smtpoutm.mac.com [17.148.16.70]) by mx1.freebsd.org (Postfix) with ESMTP id E818013C461 for ; Tue, 19 Feb 2008 20:38:12 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from mac.com (asmtp010-s [10.150.69.73]) by smtpoutm.mac.com (Xserve/smtpout007/MantshX 4.0) with ESMTP id m1JKRED3011385; Tue, 19 Feb 2008 12:27:14 -0800 (PST) Received: from mini-g4.jnpr.net (natint3.juniper.net [66.129.224.36]) (authenticated bits=0) by mac.com (Xserve/asmtp010/MantshX 4.0) with ESMTP id m1JKRBpd029413 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 19 Feb 2008 12:27:12 -0800 (PST) Message-Id: From: Marcel Moolenaar To: Oliver Fromme In-Reply-To: <200802191943.m1JJhdrJ044356@lurza.secnetix.de> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v919.2) Date: Tue, 19 Feb 2008 12:27:06 -0800 References: <200802191943.m1JJhdrJ044356@lurza.secnetix.de> X-Mailer: Apple Mail (2.919.2) Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: /boot/loader graphics support & extensibility X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2008 20:38:13 -0000 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