cvs commit: src/lib/libc/sys mincore.2 src/sys/vm vm_mmap.c
Alan Cox
alc at cs.rice.edu
Wed Jun 21 18:25:55 UTC 2006
John Baldwin wrote:
>On Wednesday 21 June 2006 13:58, John-Mark Gurney wrote:
>
>
>>Alan Cox wrote this message on Wed, Jun 21, 2006 at 12:44 -0500:
>>
>>
>>>John-Mark Gurney wrote:
>>>
>>>
>>>
>>>>Konstantin Belousov wrote this message on Wed, Jun 21, 2006 at 12:59
>>>>
>>>>
>+0000:
>
>
>>>>>Modified files:
>>>>> lib/libc/sys mincore.2
>>>>> sys/vm vm_mmap.c
>>>>>Log:
>>>>>Make the mincore(2) return ENOMEM when requested range is not fully
>>>>>mapped.
>>>>>
>>>>>
>>>>Is this change to be posix compliant or something? ENOMEM seems like
>>>>the wrong error, or are we allocating memory?
>>>>#define ENOMEM 12 /* Cannot allocate memory */
>>>>
>>>>the original EINVAL seems to me the correct one, as is commonly used
>>>>when the data passed in is incorrect...
>>>>
>>>>
>>>I looked at this when the patch was proposed. ENOMEM is the de facto
>>>standard error for this case. To the best of my knowledge, there is no
>>>officially-sanctioned specification for mincore(2).
>>>
>>>
>>Could you please provide a reference to this de facto standard error
>>as in other places where ENOMEM is used for such an error?
>>
>>
>
>NetBSD and Linux were the examples given on the thread in hackers at . Check the
>archives.
>
>
>
You can add AIX and Solaris to that list. Every system that I found
that supports mincore(2) returns ENOMEM in this case.
Alan
More information about the cvs-src
mailing list