include: Prefix includes to use a scope

[yperess]

Move include paths and add new target_include_directories to support
backwards compatibility:

• /include -> /include/zephyr
  example: <irq.h> -> <zephyr/irq.h>
• /kernel/include -> /kernel/include/zephyr/kernel/
  example: <thread.h> -> <zephyr/kernel/threads.h>

Issue #41543

Signed-off-by: Yuval Peress peress@google.com

[yperess]

/kernel/include -> /kernel/include/zephyr/kernel/

why is this needed given that kerne/include is internal?

My thinking was to de-risk. While others may not #include <zephyr/kernel/mmu.h> there's nothing stopping an application from using another third party library that also has mmu.h. In that case (depending on how imports were done) even the internal build of Zephyr might confuse the Zephyr version of mmu.h and the other third party version. Also, it adds consistency.

[stephanosio]

there's nothing stopping an application from using another third party library that also has mmu.h.

so there are two cases:

1. application code including the header files under kernel/include
2. kernel code including header files from the application(s)

The 1st case is not possible since kernel/include is only visible to the source files under kernel/ and arch/.
The 2nd case should not be possible either since applications should limit the scope of their include exports to the application target(s).

In that sense, I agree that the kernel/include change should not be done.

[nashif]

My thinking was to de-risk. While others may not #include <zephyr/kernel/mmu.h> there's nothing stopping an application from using another third party library that also has mmu.h. In that case (depending on how imports were done) even the internal build of Zephyr might confuse the Zephyr version of mmu.h and the other third party version. Also, it adds consistency.

being able to include <zephyr/kernel/mmu.h> and being on the level and under the same namespace makes it look like this header is public and can be used by anyone.

[stephanosio]

This can probably stay as include/posix since the POSIX headers were placed under include/posix/ instead of include/ for the very same reason (i.e. namespace conflict issues), and the header files under include/posix/ are not really "Zephyr headers;" but no strong opinion here.

FYI @cfriedt

[yperess]

Looks like I missed a file at include/zephyr/types.h pushed again with that move

[povergoing]

+1 refresh