LinuxKPI: extract stringify() in their own header file

[bz]

Summary

Add linux/stringify.h as directly included by drivers. Remove the
definitions from compiler.h and include the new header in places
where the stringify macros are already used without linuxkpi.

I have adjusted the Copyright of the new file according to the commit
originaly adding the macros (99e690772adbcb78c9e8441bedcf1913d72ea72f).

Sposnored by: The FreeBSD Foundation
MFC after: 2 weeks
Reviewed by:
Differential Revision:

[bz]

@manu my test build found that this will break drm-kmod ( linuxkpi/dummy/include/linux/stringify.h exists ).
How do you deal with dummy files no longer needed in 14 but still needed in 13?

[manu]

In D30440#683967, @bz wrote:

@manu my test build found that this will break drm-kmod ( linuxkpi/dummy/include/linux/stringify.h exists ).
How do you deal with dummy files no longer needed in 14 but still needed in 13?

This has not happened before.
I guess it breaks because some stuff in drm-kmod uses __stringify and it's not defined anymore ?
The easiest way to solve this would be to remove the dummy file and add a new one in linuxkpi/gplv2/include/ which check FreeBSD_version and include_next if the version matches.

[bz]

In D30440#683998, @manu wrote:

In D30440#683967, @bz wrote:

@manu my test build found that this will break drm-kmod ( linuxkpi/dummy/include/linux/stringify.h exists ).
How do you deal with dummy files no longer needed in 14 but still needed in 13?

This has not happened before.
I guess it breaks because some stuff in drm-kmod uses __stringify and it's not defined anymore ?
The easiest way to solve this would be to remove the dummy file and add a new one in linuxkpi/gplv2/include/ which check FreeBSD_version and include_next if the version matches.

Thank you for the quick answer! I'll prepare that (also for cpu.h) and possible other things I find and send a pull request.