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