9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: Christian Smith <csmith@micromuse.com>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] Plan9 in VMware?
Date: Tue, 13 Feb 2001 21:28:03 +0000	[thread overview]
Message-ID: <Pine.LNX.4.21.0102132118140.9468-100000@erol.dev.net> (raw)
In-Reply-To: <20010213195620.0362919A05@mail.cse.psu.edu>

Is acceleration really that important to get bootstrapped? At least when
in a VESA mode, you can then develop any acceleration on top of it. Linux
has no problems running at useable speeds in VESA modes.

As far as your other reservations, VESA defines a protected mode interface
which requires only (from memory):
1. Permissions to the ports used to program the controller.
2. Valid ds, ss and cs segments.

Once the mode is set up, acceleration details can be creamed off from
XFree86 sources.

So long as entry to the interface is serialised by the plan9 VESA driver,
then SMP should not be a problem.

Christian

On Tue, 13 Feb 2001, Russ Cox wrote:

>	Grr, all plan9 needs is a VESA 2.0 video driver. I know someone has talked
>	about doing this (can't remember the reference,) and I intend to have a go
>	myself once I've got plan9 up and running. Then we can dump all this
>	reliance on bios signatures etc.
>
>	I have to say, the way plan9 handles this stuff is surprisingly archaic!
>
>I believe Roger Peppe did this for Inferno.
>I explored doing it for Plan 9 a month ago
>and got frustrated: by the x86 arcana needed
>to pull it off, by the prospect of needing to
>set up the graphics card in the boot loader
>before doing the 32-bit mode switch, by the
>blind faith you need to trust the video calls to
>come back to you, by the fact that the VESA
>interface doesn't handle any acceleration so
>you'd still have to obtain chipset manuals to do that,
>by the fact that nowhere does the VESA spec
>guarantee that it will work on multiprocessors.
>
>I agree that card identification using BIOS strings
>should go, in favor of something like PCI ids,
>but it looks like we'll be stuck writing card-specific
>drivers for a long while still.  Everyone else does.
>
>The hard part is not writing the drivers.  The hard
>part (as discussed before) is getting the manuals
>from the manufacturers.  Since acceleration requires
>this anyway, the VESA stuff just doesn't seem worth it.
>
>Please, prove me wrong.  I'd love to see it.
>
>Russ
>

--
    /"\
    \ /    ASCII RIBBON CAMPAIGN - AGAINST HTML MAIL
     X                           - AGAINST MS ATTACHMENTS
    / \



  reply	other threads:[~2001-02-13 21:28 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-02-13 19:56 Russ Cox
2001-02-13 21:28 ` Christian Smith [this message]
2001-02-13 21:34   ` Scott Schwartz
  -- strict thread matches above, loose matches on Subject: below --
2001-02-14 12:49 rog
2001-02-13 22:24 forsyth
2001-02-05  9:56 Jim Niemira
2001-02-05 14:22 ` Ish Rattan
2001-02-13 14:20   ` Jim Niemira
2001-02-13 15:13     ` Christian Smith

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=Pine.LNX.4.21.0102132118140.9468-100000@erol.dev.net \
    --to=csmith@micromuse.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).