From: Dmitry Torokhov on
On Sunday 09 May 2010 01:20:44 am H. Peter Anvin wrote:
> 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.
>

Source please? I was not aware that there was a standard governing
returns code for module init methods.

--
Dmitry
--
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: Dmitry Torokhov on
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.

Thanks.

--
Dmitry
--
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: Dmitry Torokhov on
On Monday 10 May 2010 10:30:43 am H. Peter Anvin wrote:
> 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.

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.

Solaris ldi:

ENODEV

Requested device does not exist.

ENXIO

Unsupported device operation or access mode.

and so on...

--
Dmitry
--
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/