Hi all, On 03/20/19 at 05:58am, Matthew Wilcox wrote: > On Wed, Mar 20, 2019 at 02:36:58PM +0200, Mike Rapoport wrote: > > There are more than a thousand -EEXIST in the kernel, I really doubt all of > > them mean "File exists" ;-) > > And yet that's what the user will see if it's ever printed with perror() > or similar. We're pretty bad at choosing errnos; look how abused > ENOSPC is: When I tried to change -EEXIST to -EBUSY, seems the returned value will return back over the whole path. And -EEXIST is checked explicitly several times during the path. acpi_memory_enable_device -> __add_pages .. -> __add_section -> sparse_add_one_section Only look into hotplug path triggered by ACPI event, there are also device memory and ballon memory paths I haven't checked carefully because not familiar with them. So from the checking, I tend to agree with Oscar and Mike. There have been so many places to use '-EEXIST' to indicate that stuffs checked have been existing. We can't deny it's inconsistent with term explanation text. While the defense is that -EEXIST is more precise to indicate a static instance has been present when we want to create it, but -EBUSY is a little blizarre. I would rather see -EBUSY is used on a device. When want to stop it or destroy it, need check if it's busy or not. #define EBUSY 16 /* Device or resource busy */ #define EEXIST 17 /* File exists */ Obviously saying resource busy or not, it violates semanics in any language. So many people use EEXIST instead, isn't it the obsolete text's fault? Personal opinion. Thanks Baoquan > > $ errno ENOSPC > ENOSPC 28 No space left on device > > net/sunrpc/auth_gss/gss_rpc_xdr.c: return -ENOSPC; > > ... that's an authentication failure, not "I've run out of disc space".
