From owner-freebsd-arch@FreeBSD.ORG Tue Jul 27 16:36:47 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 66F0A16A4CF for ; Tue, 27 Jul 2004 16:36:47 +0000 (GMT) Received: from out010.verizon.net (out010pub.verizon.net [206.46.170.133]) by mx1.FreeBSD.org (Postfix) with ESMTP id DF9D943D31 for ; Tue, 27 Jul 2004 16:36:46 +0000 (GMT) (envelope-from babkin@bellatlantic.net) Received: from bellatlantic.net ([138.89.157.57]) by out010.verizon.net (InterMail vM.5.01.06.06 201-253-122-130-106-20030910) with ESMTP id <20040727163645.WQML14383.out010.verizon.net@bellatlantic.net>; Tue, 27 Jul 2004 11:36:45 -0500 Sender: root@FreeBSD.ORG Message-ID: <41068499.CACDAEB0@bellatlantic.net> Date: Tue, 27 Jul 2004 12:36:41 -0400 From: Sergey Babkin X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 4.7-RELEASE i386) X-Accept-Language: en, ru MIME-Version: 1.0 To: Peter Jeremy References: <20040718184008.GC57678@darkness.comp.waw.pl> <20040719075952.GG57678@darkness.comp.waw.pl> <200407191855.19885.max@love2party.net> <4105987E.5FC50517@bellatlantic.net> <20040727084324.GM3001@cirb503493.alcatel.com.au> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit X-Authentication-Info: Submitted using SMTP AUTH at out010.verizon.net from [138.89.157.57] at Tue, 27 Jul 2004 11:36:44 -0500 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 16:36:47 -0000 Peter Jeremy wrote: > > [ /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 think any one error is good enough. Especially that EPERM and ENOENT would be returned from open(), not write(). > Overall, IMHO, the benefits are minimal and don't warrant the effort > of implementing and maintaining the code. Oh, come on: the code is already implemented by someone and requires zero maintenance. I mean, when was the last time someone touched the implementation of /dev/null? BTW, probably an easy implementation would be to just add one more minor to the null driver. -SB