From owner-freebsd-hackers  Mon Sep 23 11:46:58 1996
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id LAA08223
          for hackers-outgoing; Mon, 23 Sep 1996 11:46:58 -0700 (PDT)
Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211])
          by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id LAA08203
          for <freebsd-hackers@FreeBSD.org>; Mon, 23 Sep 1996 11:46:55 -0700 (PDT)
Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA02548; Mon, 23 Sep 1996 11:43:20 -0700
From: Terry Lambert <terry@lambert.org>
Message-Id: <199609231843.LAA02548@phaeton.artisoft.com>
Subject: Re: splash-page on bootup..
To: msmith@atrad.adelaide.edu.au (Michael Smith)
Date: Mon, 23 Sep 1996 11:43:20 -0700 (MST)
Cc: terry@lambert.org, msmith@atrad.adelaide.edu.au,
        jgreco@brasil.moneng.mei.com, brandon@glacier.cold.org,
        freebsd-hackers@FreeBSD.org
In-Reply-To: <199609230148.LAA21904@genesis.atrad.adelaide.edu.au> from "Michael Smith" at Sep 23, 96 11:18:25 am
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-hackers@FreeBSD.org
X-Loop: FreeBSD.org
Precedence: bulk

> > This is only because we are stupid and use DELAY() instead of a
> > calibrated timer list of one-shot outcall functions.  Using a
> > spinloop is just inherently stupid.
> 
> Uh?  You are still thinking like a CS guy, not a hardware programmer.

"Sum id quod sum et id totum est quod sum."
(I yam what I yam 8-)).


> When I am looking for some hardware in a probe routine, I want _nothing_
> _nada_ _zip_ happening behind my back.  No interrupts, no "strategically
> placed callbacks", nothing.
> 
> This has nothing to do with how DELAY() works, it's basic 'least surprise'
> stuff.

You could make the same argument against using virtual memory.  8-|.

>From a process perspective on a timesharing machine, nothing *is*
happening "behind its back" to the virtual machine in which the
process resides.

It's "basic fractal complexity stuff": you look at the whole system,
and it's complicated.  You look at the process runtime environment
from the process perspective, and it's vastly less complicated (but
it is the same system).


					Regards,
					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.