From owner-freebsd-hackers  Tue Feb 11 22:35:40 1997
Return-Path: <owner-hackers>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.5/8.8.5) id WAA07000
          for hackers-outgoing; Tue, 11 Feb 1997 22:35:40 -0800 (PST)
Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38])
          by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id WAA06982
          for <freebsd-hackers@freebsd.org>; Tue, 11 Feb 1997 22:35:28 -0800 (PST)
Received: from current1.whistle.com (current1.whistle.com [207.76.205.22])
          by alpo.whistle.com (8.8.5/8.8.4) with SMTP
	  id WAA06201; Tue, 11 Feb 1997 22:30:33 -0800 (PST)
Message-ID: <33016316.41C67EA6@whistle.com>
Date: Tue, 11 Feb 1997 22:28:38 -0800
From: Julian Elischer <julian@whistle.com>
Organization: Whistle Communications
X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2-CURRENT i386)
MIME-Version: 1.0
To: Terry Lambert <terry@lambert.org>
CC: Simon Shapiro <Shimon@i-Connect.Net>, freebsd-hackers@freebsd.org
Subject: Re: Raw I/O Question
References: <199702112244.PAA29164@phaeton.artisoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

Terry Lambert wrote:
> 
> > Can someone take a moment and describe briefly the execution path of a
> > lseek/read/write system call to a raw (character) SCSI partition?

> 
> You skipped a specification step: the FS layout on that partition.
> I will assume FFS with 8k block size (the default).

Terry, in your description you forget he's asking for
RAW devices..

>
>         -> read syscall
>         -> fill out uio struct
>         -> call VOP_READ using bogus fileops struct dereference
>            which is there because named pipes and UNIX domain
>            sockets aren't in the VFS like they should be
>         -> ffs_read (/sys/ufs/ufs/ufs_readwrite.c:READ)
>         -> (called iteratively)
>                 bread
>                 -> getblk
>                    (in cache?  No?)
>                    -> vfs_busy_pages
>                       VOP_STRATEGY
>                       -> VCALL strategy routine for device vnode
>                       -> spec_strategy (/sys/miscfs/specfs/spec_vnops.c)
>                       -> call device strategy through bdevsw[]
>                       -> generic scsi (scbus [bus interface]/sd [disk
>                          interface]
>                       -> actual controller requests
>                       biowait
>                 uiomove
>                 -> copyout
> 
for a raw device..
raw_read()
calls physio,
which faults in and wires down pages in the user space
for the buffer (in case they are out)
then it takes the phyical addresses
and applies them to a reerved section of kernel VM space.
it then calls the strategy routine for the device
which gets the kv region, 
and extracts the phyical addresses again and 
sets up the DMA
and then waits

DMA is directly into the users pages..

> write
>         -> write syscall
>         -> fill out uio struct
>         -> call VOP_WRITE using bogus fileops struct dereference
>            which is there because named pipes and UNIX domain
>            sockets aren't in the VFS like they should be
>         -> ffs_write (/sys/ufs/ufs/ufs_readwrite.c:WRITE)
>         -> (called iteratively)
>                 (partial FS block? !!!CALL READ!!!
>                 -> fill in modified areas of partial FS block
>                    (uiomove)
>                    -> copyin

nope.. not in raw devices.

>                 bwrite
>         ...
d