From owner-freebsd-current@FreeBSD.ORG Mon Oct 25 20:34:05 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BB7D1106566C for ; Mon, 25 Oct 2010 20:34:05 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id 722A08FC19 for ; Mon, 25 Oct 2010 20:34:05 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1PATk0-0002pD-LN for freebsd-current@freebsd.org; Mon, 25 Oct 2010 22:34:00 +0200 Received: from 78-1-180-0.adsl.net.t-com.hr ([78.1.180.0]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 25 Oct 2010 22:34:00 +0200 Received: from ivoras by 78-1-180-0.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 25 Oct 2010 22:34:00 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Ivan Voras Date: Mon, 25 Oct 2010 22:33:51 +0200 Lines: 33 Message-ID: References: <4CC5D83E.8030505@delphij.net> <4CC5D9DB.1020409@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: 78-1-180-0.adsl.net.t-com.hr User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.9) Gecko/20101008 Thunderbird/3.1.4 In-Reply-To: Subject: Re: [RFC] More meaningful information about ENOEXEC for kldload(8) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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, 25 Oct 2010 20:34:05 -0000 On 10/25/10 22:13, Garrett Cooper wrote: > On Mon, Oct 25, 2010 at 12:26 PM, Doug Barton wrote: >> On 10/25/2010 12:19, Xin LI wrote: >>> >>> Here is a simple patch that adds more meaning messages when kldload hits >>> ENOEXEC. >> >> +1 on anything that makes this (and related) error more clear. I know I've >> stumbled over it numerous times. > > Typo in the error message aside... > Technically you can dig the source of these errors from > /var/log/messages // syslog though, Yes... > so why not just keep status quo? And no :) I've often encountered the kldload failure and I've always had to look at the kernel logs to find out the actual reason. There are several cases where kldload can fail, including recursively - when a module fails to load as a dependancy of the module the user is trying to load, for all the reasons a module can fail to load. I think something should be done to make the message more descriptive but statically changing the error message isn't it (except if the message is changed to say "please look at the kernel syslog messages to find out the real reason for this failure"). The best version would be to export more data about what exactly was the failure and where it happened.