Re: [9fans] hardware acceleration

[George Michaelson <ggm@dstc.edu.au>]

  	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