From: H. Peter Anvin on
On 05/09/2010 01:19 AM, tip-bot for H. Peter Anvin wrote:
>
> MODULE_AUTHOR("VMware, Inc.");
> MODULE_DESCRIPTION("VMware Memory Control (Balloon) Driver");
> @@ -767,7 +767,7 @@ static int __init vmballoon_init(void)
> * Check if we are running on VMware's hypervisor and bail out
> * if we are not.
> */
> - if (!vmware_platform())
> + if (x86_hyper != &x86_hyper_vmware)
> return -ENODEV;
>
> vmballoon_wq = create_freezeable_workqueue("vmmemctl");

Note: I did not change the existing code, but this is an example of a
very common bug: the appropriate error code for "hardware is not
present" is ENXIO, not ENODEV.

-hpa

--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: H. Peter Anvin on
On 05/10/2010 01:06 AM, Dmitry Torokhov wrote:
>
> Source please? I was not aware that there was a standard governing
> returns code for module init methods.
>

ENODEV means "not a device node."
ENXIO means "hardware not present."

-hpa

--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: H. Peter Anvin on
On 05/10/2010 09:17 AM, Dmitry Torokhov wrote:
> On Monday 10 May 2010 08:23:28 am H. Peter Anvin wrote:
>> On 05/10/2010 01:06 AM, Dmitry Torokhov wrote:
>>> Source please? I was not aware that there was a standard governing
>>> returns code for module init methods.
>>
>> ENODEV means "not a device node."
>> ENXIO means "hardware not present."
>>
>
> There is no device node in question. Again, could you please point me to
> the list of allowed error codes for init methods? According to SUS,
> we need to follow ERROR section of the appropriate function, and I do
> not believe that spec covers cases if driver binding and module loading.
>
> FWIW -ENODEV is explicitly allowed in our device core and means "device
> not found", especially in context of platform devices. I do not see the
> need of changing that.
>

The problem with this abuse of ENODEV is that people start using it
elsewhere, where it *DOES* matter than ENXIO is the proper return code.
Yes, we handle incorrect uses of ENODEV, but the right thing to do is
to teach people to use ENXIO properly.

-hpa

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: H. Peter Anvin on
On 05/10/2010 10:52 AM, Dmitry Torokhov wrote:
>
> The usage that you mention only valid in the context of working with
> device nodes. In other cases it can be used to indicate different errors
> altogether:
>
> mmap:
>
> [ENODEV]
> The fildes argument refers to a file whose type is not supported
> by mmap().
>
> fallocate:
>
> [ENODEV]
> The fd argument does not refer to a regular file.
>
> Linux mount:
>
> ENODEV filesystemtype not configured in the kernel.
>
> ENXIO The major number of the block device source is out of range.
>

"The major number of the block device source is out of range" is really
nothing but confusion on the part of the man page author. It's exactly
this kind of confusion which I try to clamp down on, because we have
*so* many instances of it in the existing codebase. It seems, in fact,
to be one of the most common mistakes

ENXIO really means exactly the same thing as it does elsewhere: no
hardware for the specified device. For example, create /dev/hda on a
system with no IDE:

mount("/dev/hda", "/mnt", "ext2", MS_MGC_VAL, NULL) = -1 ENXIO (No such
device or address)

[no "out of range" anything there...]

The kernel does indeed return ENODEV for a nonexistent filesystem name,
which can only best be described as "severely confusing", but probably
have to be considered grandfathered in by now. (mount returns ENOTBLK
for a non-devicenode, which is somewhat accurate -- a non-device is not
a block device, after all...)

-hpa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/