Date: Tue, 27 Jul 2004 18:43:24 +1000 From: Peter Jeremy <PeterJeremy@optushome.com.au> To: Sergey Babkin <babkin@bellatlantic.net> Cc: freebsd-arch@freebsd.org Subject: Re: some PRs Message-ID: <20040727084324.GM3001@cirb503493.alcatel.com.au> In-Reply-To: <4105987E.5FC50517@bellatlantic.net> References: <20040718184008.GC57678@darkness.comp.waw.pl> <20040719075952.GG57678@darkness.comp.waw.pl> <200407191855.19885.max@love2party.net> <4105987E.5FC50517@bellatlantic.net>
next in thread | previous in thread | raw e-mail | index | archive | help
[ /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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040727084324.GM3001>