Re: [RFC] More meaningful information about ENOEXEC for kldload(8)

From: Garrett Cooper <gcooper_at_FreeBSD.org>
Date: Mon, 25 Oct 2010 13:13:26 -0700
On Mon, Oct 25, 2010 at 12:26 PM, Doug Barton <dougb_at_freebsd.org> 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, so why not just keep status quo?
Making errors more intuitive is nice, but providing more misleading
errors are worse than providing less misleading errors; this kind of
error message falls in the more misleading message category, as
ENOEXEC means:

     [ENOEXEC]          The file format of file was unrecognized.

    That is open for a lot of interpretation as to what the actual
error is, as this applies to the logic paths in
/sys/kern/kern_linker.c:linker_load_file (to date) on CURRENT, which
applies to both the child and parent modules.
    If anything though, I find this reasoning for hammering everything
into ENOEXEC slightly annoying:

                /*
                 * Format not recognized or otherwise unloadable.
                 * When loading a module that is statically built into
                 * the kernel EEXIST percolates back up as the return
                 * value.  Preserve this so that apps like sysinstall
                 * can recognize this special case and not post bogus
                 * dialog boxes.
                 */
                if (error != EEXIST)
                        error = ENOEXEC;

    Why doesn't the error code properly percolate up the chain if it's
not EEXIST -_-...? It's almost like there needs to be a more
descriptive means to state what the errors are and those errors should
be properly documented in the kldload(2) manpage.
Thanks,
-Garrett
Received on Mon Oct 25 2010 - 18:13:28 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:08 UTC