9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: "Russ Cox" <rsc@plan9.bell-labs.com>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] hardware acceleration
Date: Tue, 13 Feb 2001 21:28:50 -0500	[thread overview]
Message-ID: <20010214022905.645B2199D5@mail.cse.psu.edu> (raw)

  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


             reply	other threads:[~2001-02-14  2:28 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-02-14  2:28 Russ Cox [this message]
  -- strict thread matches above, loose matches on Subject: below --
2001-02-14 12:42 William Staniewicz
2001-02-14 10:24 forsyth
2001-02-14  7:44 nigel
2001-02-14  7:01 Russ Cox
2001-02-14  1:40 Russ Cox
2001-02-14  1:56 ` George Michaelson
2001-02-14  9:41   ` Douglas A. Gwyn
2001-02-14  0:45 Russ Cox
2001-02-14  1:08 ` George Michaelson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20010214022905.645B2199D5@mail.cse.psu.edu \
    --to=rsc@plan9.bell-labs.com \
    --cc=9fans@cse.psu.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).