Date: Fri, 24 Jan 2003 13:20:10 -0800 From: Marcel Moolenaar <marcel@xcllnt.net> To: Nicolas Souchu <nsouch@free.fr> Cc: arch@FreeBSD.ORG Subject: Console implementation: summary and personal conclusion Message-ID: <20030124212010.GA44543@dhcp01.pn.xcllnt.net> In-Reply-To: <20030124093430.A14066@armor.fastether> References: <20030122010246.52789.qmail@web13404.mail.yahoo.com> <1043236066.28124.6.camel@builder02.qubesoft.com> <20030122215115.GC590@dhcp01.pn.xcllnt.net> <20030124093430.A14066@armor.fastether>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Jan 24, 2003 at 09:34:30AM +0100, Nicolas Souchu wrote: > On Wed, Jan 22, 2003 at 01:51:16PM -0800, Marcel Moolenaar wrote: > > This is what's been building in my head so far. It's graph-like > > and probably too early for public exposure, but what the hee. > > Hey! You'd love KGI. From your description it looks like there's a big overlap. The major difference being that I didn't worry too much about the graphical aspect beyond elementary graphical consoles. Ok, time to summarize: o Original topic was newbusification of kbd but it was clear from the email that the intend was broader. This opened up Pandora's box. See: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=2463+0+current/freebsd-arch o The new kids on the platform block already have issues with syscons and pvct as they are both PC and ISA oriented. This also hits pccard based docking stations. Importing wscons has been suggested, but I didn't get the impression that it was a superior alternative as there are definite downsides. See for example: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=12593+0+current/freebsd-arch o KGI has been pulled in and so far (superficially) looks like the framework I had building in my head but allows or moves accelerated graphics drivers in the kernel. After reading up on it a bit more I see definite potential in that direction. See: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=18642+0+current/freebsd-arch http://docs.freebsd.org/cgi/getmsg.cgi?fetch=253924+0+current/freebsd-arch o This issue has been raised that we need to probe potential console hardware before the newbus infrastructure has been initialized and that this by itself causes the biggest non- portability. I get the impression that this point is the easiest to do wrong by making all sorts of assumptions. See: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=405180+0+current/freebsd-arch Where to go from here: First of all, we already have 2 console implementations in the tree and whatever we do, I don't think we should make that 3 or more. So, if we're going to add a new console implementation, we need to axe at least one. My ordering would be pcvt first, syscons second. I think it's easier to create pcvt compatibility than syscons compatibility. Ideally we should only have one of course. The following thoughts are battling for recognition. It is highly graphics oriented in cases. I guess it shows my preference: 1. According to current standards FreeBSD is severely lacking in the looks department. We really depend on X with GNOME, KDE or any of the other selection of colors. With sysinstall still the application that many people see as they have their first encounter with FreeBSD, the first impression can really suck in cases. Whatever we did on the looks front is i386 specific. Someday i386 will not be the primary platform or syscons may simply stop working because we don't have VGA anymore and how do we get those nifty splash screens then? 2. The security revolution we had a couple of years ago has changed much and we're more and more aware of security issues. Having a userland application in control of hardware seems very odd in that light. We have put our faith in userland to not hose the hardware or to prevent one process to look at data that belongs to another process. Can we trust X to prevent reading/writing outside the area of the display that is assigned to us? 3. We have a bunch of network hardware drivers and a sound infra- structure that supports many controllers. Yet, when it comes to graphics adapters we seem to apply a different standard. What makes a graphics infrastructure so different from a sound infra- structure other than that it is designed to annoy the eyes and not the ears. 4. I really hate to have the kernel double in size because we have to have a bloody graphics engine in a headless machine or a machine that is shipped with a 3D graphics adapter because you get 3D graphics adapters with everything you buy and all you want to do is attach a monitor and keyboard once in a while because you don't have any other means for a console and all you want is text. 5. We are very likely not going to write high-performance graphics drivers by ourselves. A complex infrastructure that is not used in practice is rather pointless. A much simpler or limited approach has a higher chance of being successful and we may actually have it before we have our 10th anniversary. I think that if we focus on our immediate needs, but don't cut corners that can't be "uncut" we should go for something like KGI. We already have a vga and tga driver and those can be used to bootstrap something new. Even if we have to write a driver from scratch, we don't have to write a 2D/3D accelerator. Get a portable console implemetation first, even if it's text-only. If we make sure we can provide compatibility with pcvt, we can keep syscons for i386. After that, we can work on the future... Thoughts? -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030124212010.GA44543>