Hi Lucas, On 12/31/2012 02:28 PM, Lucas De Marchi wrote:
relying on the return code of a binary is one thing that can break very easily.
Agreed, but currently the only difference in behavior of e.g. insmod for module load failures that have different causes is printing of a different message, which is even less reliable than a return code.
Could you share why you need to distinguish between the causes of failures.
During the installation process of our GPU driver, our installer builds a module and then test loads it as a basic sanity check. When the test load fails, we'd like to have a little more insight into why it failed, so that we can take directed action for specific failure cases: this could either be going down a path intended to correct the problem, or simply printing a targeted help message to the user.
An example use case where it would be useful to know the specific reason for module load failure is trying to load a module without a valid and trusted cryptographic signature into a kernel that is configured to require signed modules, e.g. on a UEFI system running in secure boot mode.
This might as well break current code which relies on the current return code.
Since right now those utilities return 1 in case of *any* failure, it would only break code that looks for errors by explicitly testing for a return code == 1, as opposed to != 0. I would generally consider explicitly testing for a return code of 1 to be a bug, and as you say, relying on the return code of a binary is one thing that can break very easily. I think that any users of insmod/modprobe adversely affected by this change would understand, and the fix for any resulting breakage should be trivial, in any case.
btw we don't use s-o-b in kmod.
Okay; thanks. Feel free to remove it. -- 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
