From mboxrd@z Thu Jan 1 00:00:00 1970 To: 9fans@cse.psu.edu Subject: Re: [9fans] hardware acceleration In-reply-to: Your message of "Tue, 13 Feb 2001 20:40:09 EST." <20010214014018.3E196199D5@mail.cse.psu.edu> Message-ID: <20939.982115789@dstc.edu.au> From: George Michaelson Date: Wed, 14 Feb 2001 11:56:29 +1000 Topicbox-Message-UUID: 62e9cc2e-eac9-11e9-9e20-41e7f4b1d025 because frankly, the install process is baroque. Besides the VESA problems (which I really would like to see done, but I've a thesis to write and currently don't even have a working Plan 9 terminal) what else could be improved? I'm always interested in ways to make it better. The hardware detection aspect is admittedly not as good as it could be, but that's a problem permeating the system rather than a shortcoming of the install process. Are there other inadequacies that stand out? No. the one killer is that you have to 'know' your own h/w intimately to pre-tell the installer how to work. That the outputs appear to be DOS editable files on a DOS readable floppy isn't well exposed in the README or web: if the GUI is erally just fronting a script creation and little or no binary at the backend changes, exposing this would make it much simpler: tell people how to write the config and have one image to maintain. Other operating systems manage to do single-disk install in a couple of ways: either by booting enough network state to download the rest of the code needed, by cheating and being a 2.88Mb japanese floppy on a CD, or by doing text only install, and having a kernel which is overloaded with uncompressers, binary code melded into one mega-sh-on-steroids-with all-the-_main_-as-procedures [see, I can't count, thats three] -What plan 9 install is doing isn't clear to me because its deciding to need gfx very early on, and fails. How about writing it to drive off the serial port, and bypassing the screen altogether for some level of bootstrap? Others have done this (in text mode, which amounts to the same thing). The problem is that it's not a particularly usable system -- without rio, there's no functional equivalent of job control or even an interrupt key, so the result is a bit tough to use. But if you want to do it, the diffs are in the archives. Its a bootstrap loop: I can't do diddly with the hardware I have because I cant get beyond my card to install. Um, is it really that tightly coupled to a GUI? I didn't pick up on that. I'd assumed there were low level primitives to drive this totally from a kb->ASCII input method. why can't rio handle a non-graphical stream? I used to wonder how ls in UNIX could tell the input wasn't a tty and decide not to columnate the listing, but once I realized it was doing something like isatty() it didn't really offend me that it did. Sure, in a purist world it would not columnate, but are we that anal? If the installer 'needs' a GUI then given the debate over the last few years, which side of the anal debate is plan 9? My god! Sunos used to use pictures of VME disks and a sliding graphic of the free space hog, pre-X11, they ditched it for text! I started to write a reply to the VESA discussion earlier this evening, in which I complained that VBE < 3.0 (by far the common case) needs a real-mode call to jumpstart it, and that would mean passing the info about graphics mode through the boot loaders. There's no room for font data and graphics code in ld.com, and I'd rather keep it out of 9load too. While writing this it occurred to me that we can probably defer the switch from text to graphics mode, so I canned the reply. If you're thinking of delaying the switch, isn't is possible a bunch of stuff could be done in textmode like disk layout and write-to-disk such that when you do fail, whats left on-disk is closer to usable? or that a decision to go with a 2-floppy install would permit debug/fixit tools to be available? Then again, if you want VBE 1.2, you need to do the graphics switch right away, and all the problems come back. I did a google search for XFree86 startup dumps and found that there were a huge number of VBE 1.2 (non-VBE 2.0) cards still out there, so it seems reasonable to want to support them. I've always assumed the linux direct to frame-buffer drivers and bindings onto them were the way to go. Last time I did a redhat (for work, never for home) it was 640x480x8 and 'just worked' -but was it pulling in a mini-X11 or was it doing frobs on framebuffer? An approach that works even for VBE 1.2 is to simulate the BIOS code rather than run it directly. The Alpha PC does this in firmware, I'm told. I wrote a 3000-line real mode x86 emulator that seems to do a decent job, and it keeps the x86 creepiness contained. The only problem is that the mode switch on my particular card makes some INT 15 calls to grub around PCI space, and simulating those in turn requires turning off interrupts, which I'd rather not do from user space. Answering the INT15 calls directly is probably enough to get the mode switches working, but I haven't gotten back to it. Oh, getting a thesis is definately more important [no joke] but while you aren't... *why* didn't you want to turn off interrupts at that point? -Its an install process, its inherently single-user state, whats the risk? Look, I'm an outsider. A classic whiner. I'm not going to write code, you should de-rate my input by a minimum of 2 orders of magnitude to anybody else. Its not impossible you could sink hours into VESA mode and other people or me would still whine. However, I don't have an Iron Bar, and I don't wear a flak jacket. So telling me to shut up or go away has a very low downside risk. cheers -George -- George Michaelson | DSTC Pty Ltd Email: ggm@dstc.edu.au | University of Qld 4072 Phone: +61 7 3365 4310 | Australia Fax: +61 7 3365 4311 | http://www.dstc.edu.au