From owner-freebsd-hackers Thu Dec 6 12:46:35 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from laas.laas.fr (laas.laas.fr [140.93.0.15]) by hub.freebsd.org (Postfix) with ESMTP id ECCF037B405 for ; Thu, 6 Dec 2001 12:46:28 -0800 (PST) Received: from grieg.laas.fr (grieg [140.93.21.52]) by laas.laas.fr (8.12.1/8.12.1) with ESMTP id fB6KkLq8010416; Thu, 6 Dec 2001 21:46:21 +0100 (CET) Received: from tempest.rod.fr (mail@pppport3 [140.93.18.104]) by grieg.laas.fr (8.11.3/8.11.3) with ESMTP id fB6KkHv25917; Thu, 6 Dec 2001 21:46:18 +0100 (MET) Received: from ortalo by tempest.rod.fr with local-esmtp (Exim 3.12 #1 (Debian)) id 16C5Jz-00007t-00; Thu, 06 Dec 2001 21:40:43 +0100 Date: Thu, 6 Dec 2001 21:40:43 +0100 (CET) From: Rodolphe Ortalo X-Sender: ortalo@tempest.rod.fr To: Brooks Davis Cc: "Brian S. Julin" , Nicolas Souchu , freebsd-hackers@freebsd.org, KGI Devel Subject: Re: kld VM pager In-Reply-To: <20011206110008.B4782@Odin.AC.HMC.Edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, 6 Dec 2001, Brooks Davis wrote: [...] > If it got us a port sooner with fewer bugs, I'd certaintly be happy to > see the FreeBSD port not support ancient hardware. Linux and NetBSD are > both doing an excelent job in that space. IMHO, it's not only about supporting ancient (graphics) hardware. Even if FreeBSD is not actively ported to as many architectures as NetBSD, it still surely has the capacity to be ported to these architectures. Graphics hardware apparently loves to play with adressing schemes and esoteric RAM features (something understandable when you look at this kind of hardware in more details: SGRAM block modes, dual ported RAM, Sun's "3D RAM", LUT everywhere and in every possible direction, bus-mastering, texture-page-tables, etc, ...). So it seems to me that a graphics driver framework like KGI really needs some way to take into account these features, and allow userspace applications to use a much more conventional uniform and linear view of all these memory areas. It does not mean that we want to actively support all of them, but not taking into account this variety may lead us to an architecture that would not be able to adapt to future evolutions. (IMO, microcode memory areas are the "tricky" MMIO areas of the future: applications will want to access them to program their own specialized 3D graphic pipes...) Rodolphe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message