From owner-freebsd-hackers  Tue Apr  2 12:06:07 1996
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id MAA21926
          for hackers-outgoing; Tue, 2 Apr 1996 12:06:07 -0800 (PST)
Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211])
          by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id MAA21901
          Tue, 2 Apr 1996 12:06:02 -0800 (PST)
Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA16874; Tue, 2 Apr 1996 13:00:48 -0700
From: Terry Lambert <terry@lambert.org>
Message-Id: <199604022000.NAA16874@phaeton.artisoft.com>
Subject: Re: Hacked kernel with option to disable "green" mode
To: bde@zeta.org.au (Bruce Evans)
Date: Tue, 2 Apr 1996 13:00:47 -0700 (MST)
Cc: Brett_Glass@ccgate.infoworld.com, bde@zeta.org.au,
        freebsd-hackers@freebsd.org, freebsd-hardware@freebsd.org
In-Reply-To: <199604020723.RAA01028@godzilla.zeta.org.au> from "Bruce Evans" at Apr 2, 96 05:23:05 pm
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

> Note that long waits (> 10 usec) usually only occur in initialization and
> panic dump code when it can't even use timeouts.  Most waits occur at
> interrupt time when it can't use tsleep.

Hence my suggestion to event schedule.

It would have to be coupled with a queue abstraction of interrupt
handling; specifically, a SVR4/WindowsNT style top/bottom handler
division, where the point of the service routine is to queu the
interrupt as an event and allow further interrupts.

This has the negative side effective of increasing latency, and
the positive side effect of increasing concurrency (ie: it can be
set to take another interrupt from the same device right after
the event has be queued instead of at service time).

FreeBSD's interrupt code is close to this anyway, especially with
some of the recent changes.

The timer interrupt is an event trigger.  For long duration events
which can take place "after so much time has elapsed" instead of
"when so much time has elapsed", hooking the standard timer interrupt
with a function callback is perfectly acceptable.

> >Of course, pausing 30 seconds in the kernel could be catastrophic for some
> >applications,
> 
> Perhaps more importantly, pausing 30 seconds outside the kernel may be
> catastrophic :-).  There is probably little difference where the wait
> occurs except on multi-disk-controller systems where the IDE controller
> is little used.

This is not an issue if the quantum period times the number of
ready-to-run processes does not exceed the maximum allowable
delay period (which is why the timer is unacceptable for moving
"ft" functionality into the floppy tape driver in the kernel).

> >so implementing some of those proprietary commands is still
> >useful. The modification I sent in covers Seagate's.
> 
> It can't be used in the standard driver because its operation is unknown.
> It might format the drives...

Yes, I agree.  It should be a standalone command using the wdcontrol()
interface that the user must specify, with knowledge of the potential
consequences, instead of a config option that a user might say "this
looks like what I need -- I'll try it".


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