On 9/29/09, Alan Jenkins <sourcejedi.lkml@xxxxxxxxxxxxxx> wrote:
>> When calling modprobe -q with a non-existing module, it returns with
>> exit code 1. According to the manpage, modprobe "normally" will report
>> an error, and with -q shouldn't, so I believe the exist code should
>> always be 0, at least that seems to be the assumption in some init
>> scripts (e.g. binfmt-support).
>
> That part is ambiguous, but I guess "modprobe will simply ignore any
> bogus names" is pretty clear.
>
> ... and comments in the git log imply we _used_ to get this right.
>
> ""
>
> Andreas, at first glance this regression is due to your commit
> 73bdf4ab. Care to submit a patch to revert the relevant lines?
Sorry, I completely misread both the git log comments and Andreas'
code. This isn't a regression, it's more of a feature request.
The manpage does say modprobe -q "will simply ignore any bogus names",
implying that modprobe should return success in this case. But
test-modprobe/19quiet.sh has always required "modprobe -q crap" to
return failure.
So this is intentional at some level, we've always done it this way in
the past, and we need to consider the risk of breaking scripts which
expect the current behaviour.
The binfmt-support initscript seems a bad example to me. It does this
# comments added by me
set -e # abort if any command fails
...
modprobe -q binfmt_misc # this will cause an abort if
binfmt_misc.ko doesn't exist...
mount -t binfmt_misc ... # but so will this
It's only a problem if binfmt_misc is built into the kernel. However,
this will be solved by the modules.builtin work.
So I think we would need a better justification to change this.
Regards
Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-modules" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
