From owner-freebsd-current@FreeBSD.ORG Mon Jul 12 20:55:44 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6F7A116A4CE; Mon, 12 Jul 2004 20:55:44 +0000 (GMT) Received: from blake.polstra.com (blake.polstra.com [64.81.189.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 110DF43D31; Mon, 12 Jul 2004 20:55:44 +0000 (GMT) (envelope-from jdp@polstra.com) Received: from strings.polstra.com (dsl081-189-067.sea1.dsl.speakeasy.net [64.81.189.67]) by blake.polstra.com (8.12.11/8.12.11) with ESMTP id i6CKthaH079316 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 Jul 2004 13:55:43 -0700 (PDT) (envelope-from jdp@strings.polstra.com) Received: (from jdp@localhost) by strings.polstra.com (8.12.11/8.12.11/Submit) id i6CKthSA009220; Mon, 12 Jul 2004 13:55:43 -0700 (PDT) (envelope-from jdp) Message-ID: X-Mailer: XFMail 1.5.5 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Mon, 12 Jul 2004 13:55:43 -0700 (PDT) From: John Polstra To: Robert Watson X-Bogosity: No, tests=bogofilter, spamicity=0.222500, version=0.14.5 cc: freebsd-current@freebsd.org Subject: Re: kldload won't load X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2004 20:55:44 -0000 On 12-Jul-2004 Robert Watson wrote: > > On Mon, 12 Jul 2004, John Polstra wrote: > >> No, it needs to be fixed. It's printing a totally incorrect error >> message, and nobody should have to use dmesg to find out what's really >> happened. > > Well, the problem here is that the errno error-reporting mechanism can > report but not describe errors. We could add a new EKLDLINKER to point at > a linker error (or the like), or a whole set of new errnos, but the > mechanism even then couldn't report which symbols are missing, etc. One > or more linker-specific error values would probably be a useful start. I fully understand the implementation difficulties, but we have to be careful to observe the distinction between correct behavior and easy-to-implement behavior. The kldload(2) API doesn't support correct behavior, so that's where the focus needs to be -- not on making users feel stupid for failing to look in the dmesg output. John