From owner-freebsd-hackers  Wed Jan 31 10:36:38 1996
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id KAA26674
          for hackers-outgoing; Wed, 31 Jan 1996 10:36:38 -0800 (PST)
Received: from xi.dorm.umd.edu (xi.dorm.umd.edu [129.2.152.45])
          by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id KAA26649
          for <hackers@freebsd.org>; Wed, 31 Jan 1996 10:36:12 -0800 (PST)
Received: from xi.dorm.umd.edu (localhost [127.0.0.1]) by xi.dorm.umd.edu (8.7.3/8.6.12) with SMTP id NAA03415; Wed, 31 Jan 1996 13:35:44 -0500 (EST)
Date: Wed, 31 Jan 1996 13:35:44 -0500 (EST)
From: Sujal Patel <smpatel@wam.umd.edu>
X-Sender: smpatel@xi.dorm.umd.edu
To: Paul Traina <pst@shockwave.com>
cc: Paul LaFollette <lafollet@andante.cis.temple.edu>, hackers@freebsd.org
Subject: Re: Any interest in Quickcam Driver 
In-Reply-To: <199601311814.KAA06818@precipice.shockwave.com>
Message-ID: <Pine.BSF.3.91.960131133231.189Q-100000@xi.dorm.umd.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-hackers@freebsd.org
Precedence: bulk

On Wed, 31 Jan 1996, Paul Traina wrote:

> Yeah, I think you're right.  I was just trying to for that extra burn, but
> the ioctl() syscall overhead (to start the next scan) is as bad as the read.

Subsequent scans are starting by a lseek() back to zero in the Linux 
implementation.  I don't think that the overhead for that is really going 
to be significant, considering it takes around 100,000 I/O reads to get 
a single frame (and the fact that the kernel busy waits for the QuickCam 
to actually send data sometimes).


Sujal