From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 5 13:50:19 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C0DB91065670 for ; Wed, 5 Aug 2009 13:50:19 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 85E0F8FC12 for ; Wed, 5 Aug 2009 13:50:19 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from [IPv6:2001:7b8:3a7:0:7ca7:35a:1442:752b] (unknown [IPv6:2001:7b8:3a7:0:7ca7:35a:1442:752b]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 99F2B5C59; Wed, 5 Aug 2009 15:50:18 +0200 (CEST) Message-ID: <4A798E1B.9010109@andric.com> Date: Wed, 05 Aug 2009 15:50:19 +0200 From: Dimitry Andric User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.1.3pre) Gecko/20090801 Shredder/3.0b4pre MIME-Version: 1.0 To: Mel Flynn References: <200908041245.35926.mel.flynn+fbsd.hackers@mailing.thruhere.net> <4A78AB7C.3040406@andric.com> <200908041615.49128.mel.flynn+fbsd.hackers@mailing.thruhere.net> In-Reply-To: <200908041615.49128.mel.flynn+fbsd.hackers@mailing.thruhere.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: Spot the error X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2009 13:50:20 -0000 On 2009-08-05 02:15, Mel Flynn wrote: > I would expect "Unable to load fs: " + ENOENT. I was asking if this was > fixable, cause it looked like the code has been abstracted to the point that > specific errors were hard, but maybe I missed something. It does not seem easily fixable. The problem is that the mount command simply prints out the error of the system call, and doesn't have any idea which of the (many) parameters was wrong. You could change the returned error in this particular case to ENOENT, of course, but that might be considered even more confusing. Like, "What do you mean, that SCSI disk doesn't exist? It's right there in /dev!" One could also argue for EINVAL, but there's the bikeshed again... :)