From mboxrd@z Thu Jan  1 00:00:00 1970
From: "Russ Cox" <rsc@plan9.bell-labs.com>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] hardware acceleration
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Message-Id: <20010214022905.645B2199D5@mail.cse.psu.edu>
Date: Tue, 13 Feb 2001 21:28:50 -0500
Topicbox-Message-UUID: 62f2eff2-eac9-11e9-9e20-41e7f4b1d025

  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?

Turning off interrupts in user space means you have to
trust the user program not to do anything bad, like page
fault or go into an infinite loop; there's no recourse
when it does.  I don't trust my program and the BIOS not to misbehave,
and it would be awful to debug when it did, since the system
would just hang or reboot.

  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?

I think it pulls in a mini-X11 w/ Tk but I could be wrong.
That's the other thing -- if we had a software graphics
cursor we could at least run in some standard mode.

  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.

Yeah, it is.  The window system provides the delete => send interrupt
mapping.

  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?

Damn right we are.

  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?

The second edition install was done in CGA mode, with a custom
program that frobbed the CGA graphics memory.  People installed
the system only to find that they couldn't use it because they
only had text mode.  The rationale behind using a GUI was that
it was much easier to write the install process (it's a fairly
clean 1500 lines of shell script), and people had to run into
the VGA wall at some point so it might just as well be early.

It has the downside you point out, but for the most part I
think it has been a win.  I certainly appreciate being able to
draw new windows to look at what's going on when something
goes wrong (or to do other things entirely: I used to cpu out
and read mail while I ran test installs).

Next time I get my hands dirty I'll probably add an option
to run in text mode only, in the spirit of the diffs posted before,
for situations like yours.

My backup CD has finished writing, so I'm back to figuring
out how I broke my file system.

Russ