Re: [tip:x86/cpu] Modify the VMware balloon driver for the new x86_hyper API

[Dmitry Torokhov <dtor@vmware.com>]

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