Commit b1798910fc7f ("drbd: move UAPI headers to include/uapi/linux/")
broke compilation on targets without a hosted libc:

  ./usr/include/linux/drbd.h:18:10: fatal error: sys/types.h: No such
  file or directory

The underlying issue is that there were some constructs left over in
those headers that don't belong in uapi.

Drop the __KERNEL__-gated split in drbd.h. The !__KERNEL__ branch pulls
in <sys/types.h>, <sys/wait.h> and <limits.h> for symbols that the
header does not actually reference; they were carried over from when
this lived in include/linux/.
Replace <asm/types.h> and the entire #ifdef block with the standard
UAPI combo <linux/types.h> + <asm/byteorder.h>, which provides
__u32/__u64/__s32 and __{LITTLE,BIG}_ENDIAN_BITFIELD in both kernel
and userspace contexts.

drbd_limits.h references some enum values and the DRBD_PROT_C define
from drbd.h, but does not include it. Add the missing include while
we're here.

Drop the unprefixed DEBUG_RANGE_CHECK from drbd_limits.h. It has no
in-kernel users and pollutes the userspace namespace.

Switch the drbd.h and drbd_limits.h include guards to the _UAPI_LINUX_*
convention already used by drbd_genl.h.

Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202605101346.V2wwJqv1-lkp@intel.com/
Fixes: b1798910fc7f ("drbd: move UAPI headers to include/uapi/linux/")
Signed-off-by: Christoph Böhmwalder <christoph.boehmwalder@linbit.com>
---
 include/uapi/linux/drbd.h        | 28 +++-------------------------
 include/uapi/linux/drbd_limits.h |  8 ++++----
 2 files changed, 7 insertions(+), 29 deletions(-)

diff --git a/include/uapi/linux/drbd.h b/include/uapi/linux/drbd.h
index 5d4d677cf1ad..cf1ec3eb872f 100644
--- a/include/uapi/linux/drbd.h
+++ b/include/uapi/linux/drbd.h
@@ -11,32 +11,10 @@
 
 
 */
-#ifndef DRBD_H
-#define DRBD_H
-#include <asm/types.h>
-
-#ifdef __KERNEL__
+#ifndef _UAPI_LINUX_DRBD_H
+#define _UAPI_LINUX_DRBD_H
 #include <linux/types.h>
 #include <asm/byteorder.h>
-#else
-#include <sys/types.h>
-#include <sys/wait.h>
-#include <limits.h>
-
-/* Although the Linux source code makes a difference between
-   generic endianness and the bitfields' endianness, there is no
-   architecture as of Linux-2.6.24-rc4 where the bitfields' endianness
-   does not match the generic endianness. */
-
-#if __BYTE_ORDER == __LITTLE_ENDIAN
-#define __LITTLE_ENDIAN_BITFIELD
-#elif __BYTE_ORDER == __BIG_ENDIAN
-#define __BIG_ENDIAN_BITFIELD
-#else
-# error "sorry, weird endianness on this box"
-#endif
-
-#endif
 
 enum drbd_io_error_p {
 	EP_PASS_ON, /* FIXME should the better be named "Ignore"? */
@@ -432,4 +410,4 @@ enum drbd_state_info_bcast_reason {
 	SIB_SYNC_PROGRESS = 5,
 };
 
-#endif
+#endif /* _UAPI_LINUX_DRBD_H */
diff --git a/include/uapi/linux/drbd_limits.h b/include/uapi/linux/drbd_limits.h
index a72a102d1ca7..acefe84bc602 100644
--- a/include/uapi/linux/drbd_limits.h
+++ b/include/uapi/linux/drbd_limits.h
@@ -11,10 +11,10 @@
  * feedback about nonsense settings for certain configurable values.
  */
 
-#ifndef DRBD_LIMITS_H
-#define DRBD_LIMITS_H 1
+#ifndef _UAPI_LINUX_DRBD_LIMITS_H
+#define _UAPI_LINUX_DRBD_LIMITS_H
 
-#define DEBUG_RANGE_CHECK 0
+#include <linux/drbd.h>
 
 #define DRBD_MINOR_COUNT_MIN 1U
 #define DRBD_MINOR_COUNT_MAX 255U
@@ -248,4 +248,4 @@
 #define DRBD_RS_DISCARD_GRANULARITY_DEF 0U     /* disabled by default */
 #define DRBD_RS_DISCARD_GRANULARITY_SCALE '1' /* bytes */
 
-#endif
+#endif /* _UAPI_LINUX_DRBD_LIMITS_H */

base-commit: 8098eeb693c4cc4e774c62fbd4875197cb5578ce
-- 
2.53.0

On Wed, 13 May 2026 13:03:42 +0200, Christoph Böhmwalder wrote:
> Commit b1798910fc7f ("drbd: move UAPI headers to include/uapi/linux/")
> broke compilation on targets without a hosted libc:
> 
>   ./usr/include/linux/drbd.h:18:10: fatal error: sys/types.h: No such
>   file or directory
> 
> The underlying issue is that there were some constructs left over in
> those headers that don't belong in uapi.
> 
> [...]

Applied, thanks!

[1/1] drbd: clean up UAPI headers
      commit: d5607f1fafd7eb72ed693b6a033d96221e870edd

Best regards,
-- 
Jens Axboe