Done. How do we coordinate committing all the conflicting bits?

Moreover in-base linux/pm_qos.h is hidden from drm-kmod due to dummy include file: https://github.com/freebsd/drm-kmod/blob/master/linuxkpi/dummy/include/linux/pm_qos.h

In D34234#775056, @wulf wrote:

In D34234#775030, @bz wrote:

Done. How do we coordinate committing all the conflicting bits?

There should be no conflicts in linux/pm_qos.h bits. Currently drm-kmod uses preprocessor macros to stub cpu_latency_qos_* functions: https://github.com/freebsd/drm-kmod/blob/master/drivers/gpu/drm/drm_os_freebsd.h#L211 and ifdefs-out pm_qos_request structure occurrences: https://github.com/freebsd/drm-kmod/blob/master/drivers/gpu/drm/i915/i915_drv.h#L905

We can commit this linux/pm_qos.h to base and switch drm-kmod to use in-base cpu_latency_qos_ stubs any time after than.

I'll go and test that out then; what about D34235 ?
That might need an upfront change like (just drawn up without thinking)?
{{{

• a/linuxkpi/bsd/include/linux/uuid.h

+++ b/linuxkpi/bsd/include/linux/uuid.h
@@ -4,7 +4,10 @@
#define _LINUX_UUID_H

#include <uapi/linux/uuid.h>
+#include_next <linux/uuid.h>

+#ifndef UUID_STRING_LEN
#define UUID_STRING_LEN 36
+#endif

#endif
}}}

In D34234#775061, @bz wrote:

I'll go and test that out then; what about D34235 ?
That might need an upfront change like (just drawn up without thinking)?
{{{

• a/linuxkpi/bsd/include/linux/uuid.h

+++ b/linuxkpi/bsd/include/linux/uuid.h
@@ -4,7 +4,10 @@
#define _LINUX_UUID_H

#include <uapi/linux/uuid.h>
+#include_next <linux/uuid.h>

+#ifndef UUID_STRING_LEN
#define UUID_STRING_LEN 36
+#endif

#endif
}}}

IMO we should

1. Keep drm-kmod linux/uuid.h as is at the beginning
2. Add UUID_STRING_LEN and GUID_INIT() macros to base version of linux/uuid.h from https://github.com/freebsd/drm-kmod/blob/master/linuxkpi/gplv2/include/uapi/linux/uuid.h . It should not break drm-kmod as its version does not have #include_next
3. Drop linux/uuid.h and uapi/linux/uuid.h in drm-kmod master after previous macros have been committed to base
4. Cherry-pick headers dropping to 5.4-lts and 5.7-stable after 13.0 EOL

I'll try to test this on coming weekend too.

I was able to successfully build drm-kmod with in-base linux/pm_qos.h from D34234 and linux/uuid.h from D34235 after applying of following patch:

diff --git a/sys/compat/linuxkpi/common/include/linux/pm_qos.h b/sys/compat/linuxkpi/common/include/linux/pm_qos.h
index a4512657889..6b9d48c5be6 100644
--- a/sys/compat/linuxkpi/common/include/linux/pm_qos.h
+++ b/sys/compat/linuxkpi/common/include/linux/pm_qos.h
@@ -30,6 +30,8 @@
 #ifndef	_LINUXKPI_LINUX_PM_QOS_H
 #define	_LINUXKPI_LINUX_PM_QOS_H
 
+#define	PM_QOS_DEFAULT_VALUE	(-1)
+
 struct pm_qos_request {
 };
 
diff --git a/sys/compat/linuxkpi/common/include/linux/uuid.h b/sys/compat/linuxkpi/common/include/linux/uuid.h
index 1a88f686d37..418a0cadfee 100644
--- a/sys/compat/linuxkpi/common/include/linux/uuid.h
+++ b/sys/compat/linuxkpi/common/include/linux/uuid.h
@@ -35,6 +35,27 @@
 
 #define	UUID_STRING_LEN	36
 
+#define	GUID_INIT(x0_3, x4_5, x6_7, x8, x9, x10, x11, x12, x13, x14, x15) \
+	((guid_t) { .x = { 			\
+		[0]  =  (x0_3)        & 0xff,	\
+		[1]  = ((x0_3) >> 8)  & 0xff,	\
+		[2]  = ((x0_3) >> 16) & 0xff,	\
+		[3]  = ((x0_3) >> 24) & 0xff,	\
+		[4]  =  (x4_5)        & 0xff,	\
+		[5]  = ((x4_5) >> 8)  & 0xff,	\
+		[6]  =  (x6_7)        & 0xff,	\
+		[7]  = ((x6_7) >> 8)  & 0xff,	\
+		[8]  =  (x8),			\
+		[9]  =  (x9),			\
+		[10] =  (x10),			\
+		[11] =  (x11),			\
+		[12] =  (x12),			\
+		[13] =  (x13),			\
+		[14] =  (x14),			\
+		[15] =  (x15)			\
+ }})
+
+
 typedef struct {
 	char	x[16];
 } guid_t;

In D34234#775341, @wulf wrote:

I was able to successfully build drm-kmod with in-base linux/pm_qos.h from D34234 and linux/uuid.h from D34235 after applying of following patch:

Are you saying that doing that worked without changing anything in drm-kmod and I could go ahead and commit things? I am just asking as my compile testing with drm-kmod at a1ba3bd617626d2507f0d7ddaa2b19def7a92cdd did not compile with this.

Ah I see your follow-up commit. How soon do you anticipate these chnages will be committable/MFCable given people will need new packages?

I created PR to handle drm-devel-kmod breakage: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=261937

5.4-lts branch does not require any changes, so committing this review just now will not break package building.

will not break package building.

for 5.4-lts based ports

In D34234#775424, @wulf wrote:

will not break package building.

for 5.4-lts based ports

Sorry, I don't know which branch uses which port; i take this as MFCing to stable/13 within 3-5 days will be possible. I'll update the two reviews for you and wait for a go to commit then.

Ports tree is updated. Please commit rest of your work.