Date: Thu, 06 Feb 1997 18:46:20 -0800 (PST) From: Simon Shapiro <Shimon@i-Connect.Net> To: Julian Elischer <julian@whistle.com> Cc: freebsd-scsi@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG, "Justin T. Gibbs" <gibbs@narnia.plutotech.com> Subject: Re: Contigious (spelling?) allocation in kernel Message-ID: <XFMail.970206203440.Shimon@i-Connect.Net> In-Reply-To: <32FA657D.446B9B3D@whistle.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.970206203440.Shimon>