Date: Wed, 12 Feb 1997 00:04:37 +0100 From: j@uriah.heep.sax.de (J Wunsch) To: freebsd-hackers@FreeBSD.ORG Subject: Re: Raw I/O Question Message-ID: <Mutt.19970212000437.j@uriah.heep.sax.de> In-Reply-To: <XFMail.970211141038.Shimon@i-Connect.Net>; from Simon Shapiro on Feb 11, 1997 13:38:03 -0800 References: <XFMail.970211141038.Shimon@i-Connect.Net>
next in thread | previous in thread | raw e-mail | index | archive | help
As Simon Shapiro 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? I can't explain your observed behaviour, but here's the rough picture: . every call has to walk down through the upper VFS layers, until it eventually will arrive in specfs_vfsops (that's where the operations to /dev nodes end up) . lseek()'s are no-ops wrt. the drive operation, they are just noted by the VFS layers to later setup the request . read and write ops are finally being handed off to rawread(9) or rawrite(9), which will in turn call physio(9) (actually writing these man pages is left as an exercise to you :-) . physio will setup a buffer header for the request, call the device strategy routine, and wait for completion . the SCSI drivers attempt to issue the READ or WRITE commands for the full range as specified by the buffer header at once; since these commands take both, offset and length parameters, no separate SCSI operation is required to formulate the seek operation -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Mutt.19970212000437.j>