From owner-cvs-src@FreeBSD.ORG Sat Jun 14 12:13:22 2003 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C574F37B401; Sat, 14 Jun 2003 12:13:22 -0700 (PDT) Received: from aslan.scsiguy.com (aslan.scsiguy.com [63.229.232.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id C4C0C43FCB; Sat, 14 Jun 2003 12:13:21 -0700 (PDT) (envelope-from gibbs@scsiguy.com) Received: from localhost (aslan.scsiguy.com [63.229.232.106]) by aslan.scsiguy.com (8.12.9/8.12.8) with ESMTP id h5EJDJvl021016; Sat, 14 Jun 2003 13:13:20 -0600 (MDT) (envelope-from gibbs@scsiguy.com) Date: Sat, 14 Jun 2003 13:13:22 -0600 From: "Justin T. Gibbs" To: Maxime Henrion Message-ID: <10130000.1055618001@caspian.scsiguy.com> In-Reply-To: <20030614180559.GQ21011@elvis.mu.org> References: <200306132007.h5DK7nFw084898@repoman.freebsd.org> <113730000.1055611820@caspian.scsiguy.com> <20030614180559.GQ21011@elvis.mu.org> X-Mailer: Mulberry/3.0.3 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline cc: cvs-src@freebsd.org cc: src-committers@freebsd.org cc: cvs-all@freebsd.org Subject: Re: cvs commit: src/share/man/man9 bus_dma.9 X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jun 2003 19:13:23 -0000 > It sure doesn't make sense to combine PREREAD and POSTREAD or PREWRITE > and POSTWRITE, but I don't see what would be wrong with > PREREAD|POSTWRITE or POSTREAD|PREWRITE. One can imagine a scenario > where the device is DMA'ing some data to memory and where you DMA it > back to the device, and thus you would like to do a POSTREAD|PREWRITE. > I agree that this sounds unlikely ... It is not only unlikely, but it makes no sense. Why would you acknowledge the completion of a device dma only to turn right around and send it *unaltered* right back to the device? The only possible scenario I can think is a contrived example of verifying the integrity of the dma path. This is not a case that needs to be optimized so why force the sync operation implementations to support it? > Anyways, whether it's useful or not, I believe it would be more > consistent with other manpages to leave things as is and maybe add a > comment to tell that some combinations make no sense. It shouldn't be the manpage that forces the implementation. If you find that having flags that allow undefined behavior is "unclean", lets just change the implementation so that you specify only one value out of an enumeration and provide explict values for any allowed combined operations. -- Justin