From owner-freebsd-arch@FreeBSD.ORG Tue Jul 27 08:43:34 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7D73216A4CE for ; Tue, 27 Jul 2004 08:43:34 +0000 (GMT) Received: from mail007.syd.optusnet.com.au (mail007.syd.optusnet.com.au [211.29.132.55]) by mx1.FreeBSD.org (Postfix) with ESMTP id D945C43D2F for ; Tue, 27 Jul 2004 08:43:32 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from cirb503493.alcatel.com.au (c211-30-75-229.belrs2.nsw.optusnet.com.au [211.30.75.229]) i6R8hQo20814; Tue, 27 Jul 2004 18:43:26 +1000 Received: from cirb503493.alcatel.com.au (localhost.alcatel.com.au [127.0.0.1])i6R8hPVd019768; Tue, 27 Jul 2004 18:43:25 +1000 (EST) (envelope-from pjeremy@cirb503493.alcatel.com.au) Received: (from pjeremy@localhost)i6R8hPTn019767; Tue, 27 Jul 2004 18:43:25 +1000 (EST) (envelope-from pjeremy) Date: Tue, 27 Jul 2004 18:43:24 +1000 From: Peter Jeremy To: Sergey Babkin Message-ID: <20040727084324.GM3001@cirb503493.alcatel.com.au> References: <20040718184008.GC57678@darkness.comp.waw.pl> <20040719075952.GG57678@darkness.comp.waw.pl> <200407191855.19885.max@love2party.net> <4105987E.5FC50517@bellatlantic.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4105987E.5FC50517@bellatlantic.net> User-Agent: Mutt/1.4.2i cc: freebsd-arch@freebsd.org Subject: Re: some PRs X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jul 2004 08:43:34 -0000 [ /dev/full ] On Mon, 2004-Jul-26 19:49:18 -0400, Sergey Babkin wrote: >I'm about a week behind :-) but here are my 2 cents: it's a VERY useful >device for testing. Maybe. There are lots of other error numbers that are equally useful for testing. If you really want a way to inject known errors into I/O system calls, why not go the whole hog and implement a virtual filesystem that returns the required error: .../EPERM just returns EPERM .../ENOENT just returns EPERM etc Of course, you've then got to decide which of open(), close(), read() write(), ioctl(), fcntl() etc should succeed and which should return an error. This rapidly becomes unworkable. Overall, IMHO, the benefits are minimal and don't warrant the effort of implementing and maintaining the code. -- Peter Jeremy