From owner-freebsd-scsi  Thu Feb  6 20:18:27 1997
Return-Path: <owner-freebsd-scsi>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.5/8.8.5) id UAA01985
          for freebsd-scsi-outgoing; Thu, 6 Feb 1997 20:18:27 -0800 (PST)
Received: from who.cdrom.com (who.cdrom.com [204.216.27.3])
          by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id UAA01960;
          Thu, 6 Feb 1997 20:18:21 -0800 (PST)
Received: from sendero.i-connect.net ([206.190.144.100])
          by who.cdrom.com (8.7.5/8.6.11) with ESMTP id TAA20108
          ; Thu, 6 Feb 1997 19:36:23 -0800 (PST)
Received: (from shimon@localhost)
          by sendero.i-connect.net (8.8.5/8.8.4)
	  id UAA15807; Thu, 6 Feb 1997 20:34:41 -0800 (PST)
Message-ID: <XFMail.970206203440.Shimon@i-Connect.Net>
X-Mailer: XFMail 1.1-alpha [p0] on FreeBSD
Content-Type: text/plain; charset=iso-8859-8
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
In-Reply-To: <32FA657D.446B9B3D@whistle.com>
Date: Thu, 06 Feb 1997 18:46:20 -0800 (PST)
Organization: iConnect Corp.
From: Simon Shapiro <Shimon@i-Connect.Net>
To: Julian Elischer <julian@whistle.com>
Subject: Re: Contigious (spelling?) allocation in kernel
Cc: freebsd-scsi@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG,
        "Justin T. Gibbs" <gibbs@narnia.plutotech.com>
Sender: owner-freebsd-scsi@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk


Hi Julian Elischer;  On 06-Feb-97 you wrote: 

...

> well you could do what the swap daemon does.. it's started from the
> kernel..
> it's more a kernel PROCESS than a kernel thread.

I really do not care.  All I need is something that will allow me to
break the execution thread and resume it in a different time.

A mechanism, like another interrupt handler, software interrupts, etc.
I want to be able to accomplish two things:

1.  Return from xxx_scsi_cmd as fast as possible.
2.  Return from xxx_intr as fast as possible.
3.  Hand over the hardware processing implied by xxx_scsi_cmd to
    another entity so that this routine does not have to block on
    inb, outb and such.  IOW, I want to de-couple the scsi_cmd from
    the hardware.
4.  Hand over the logical (and error) processing implied by xxx_intr
    to another entity.  IOW, de-couple hardware issues (done in the
    intr routine) form logic, error processing, strategy and such.

Much of this work may appear meaningless on a uniprocessor, but on 
an SMP system it has many advantages, as it allows partitioning 
of the workload and running the three layers asynchronously from
each other.

Three Layers:

1.  Accept SCSI command, prepare for execution and queue.
2.  a.  Submit to hardware
    b.  Receive completion notification form hardware
3.  Analyze result, plan response and execute, reply to original
    caller.

Thanx!

Simon