Date: Fri, 18 Apr 1997 06:01:17 -0400 (EDT) From: Peter Dufault <dufault@hda.com> To: hasty@rah.star-gate.com (Amancio Hasty) Cc: terry@lambert.org, freebsd-hackers@FreeBSD.ORG Subject: Re: video capture driver interface to file system? Message-ID: <199704181001.GAA16977@hda.hda.com> In-Reply-To: <199704172335.QAA02492@rah.star-gate.com> from Amancio Hasty at "Apr 17, 97 04:35:04 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
> We need a very fast mechanism to store images to disk. Suggestions? You need to provide more info because the problem is different based on how much you're trying to store to disk, and whether it should be a normal UFS file system, etc. To do this completely you're going to have to look at your requirements (trigger condition, latency to start, latency between blocks, block size, throughput, and maximum length of run), and based on this possibly do as much as: Pre-allocate the file; pre-allocate the blocks of a file; pre-set up some control info for a transfer, mmap a set of blocks for the video card driver to dump data into; have the driver chain to the next block and interrupt you on each transfer, dump the video frames to the pre-allocated store. If you have the P1003.1b-1993 spec you'll find a proposed (not standard) real time file interface (look for the "rf_" stuff) in the back with a proposed API. However, if the rates are low enough and the pentium and bus fast enough you can do as little as to provide multiple mmapd buffers that the video driver will chain through and a SIGUSR to the logging process that dumps frames of collected data to disk through the file system - nothing fancy. This isn't synchronous because the driver is chaining to the next block at "frame done" interrupt time giving you the elasticity you need. Peter -- Peter Dufault (dufault@hda.com) Realtime Machine Control and Simulation HD Associates, Inc. Voice: 508 433 6936
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199704181001.GAA16977>