pm24.git/include/linux/limits.h, branch v5.4-rc4

linux/kernel.h: split _MAX and _MIN macros into

2019-03-08T02:31:59Z

tends to be cluttered because we often put various sort of unrelated stuff in it. So, we have split out a sensible chunk of code into a separate header from time to time. This commit splits out the *_MAX and *_MIN defines. The standard header contains various MAX, MIN constants including numerial limits. [1] I think it makes sense to move in-kernel MAX, MIN constants into include/linux/limits.h. We already have include/uapi/linux/limits.h to contain some user-space constants. I changed its include guard to _UAPI_LINUX_LIMITS_H. This change has no impact to the user-space because scripts/headers_install.sh rips off the '_UAPI' prefix from the include guards of exported headers. [1] http://pubs.opengroup.org/onlinepubs/009604499/basedefs/limits.h.html Link: http://lkml.kernel.org/r/1549156242-20806-2-git-send-email-yamada.masahiro@socionext.com Signed-off-by: Masahiro Yamada Cc: Alex Elder Cc: Alexey Dobriyan Cc: Zhang Yanmin Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

UAPI: (Scripted) Disintegrate include/linux

2012-10-13T09:46:48Z

Signed-off-by: David Howells Acked-by: Arnd Bergmann Acked-by: Thomas Gleixner Acked-by: Michael Kerrisk Acked-by: Paul E. McKenney Acked-by: Dave Jones

Remove CHILD_MAX

2007-07-17T17:23:03Z

The CHILD_MAX macro in limits.h should not be there. It claims to be the limit on processes a user can own, but its value is wrong for that. There is no constant value, but a variable resource limit (RLIMIT_NPROC). Nothing in the kernel uses CHILD_MAX. The proper thing to do according to POSIX is not to define CHILD_MAX at all. The sysconf (_SC_CHILD_MAX) implementation works by calling getrlimit. Signed-off-by: Roland McGrath Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

Remove OPEN_MAX

2007-07-17T17:23:03Z

The OPEN_MAX macro in limits.h should not be there. It claims to be the limit on file descriptors in a process, but its value is wrong for that. There is no constant value, but a variable resource limit (RLIMIT_NOFILE). Nothing in the kernel uses OPEN_MAX except things that are wrong to do so. I've submitted other patches to remove those uses. The proper thing to do according to POSIX is not to define OPEN_MAX at all. The sysconf (_SC_OPEN_MAX) implementation works by calling getrlimit. Signed-off-by: Roland McGrath Cc: "David S. Miller" Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

Linux-2.6.12-rc2

2005-04-16T22:20:36Z