Externalizing Xen public header to module

[soburi]

Origin

Xen (MIT licensed public header-only version)
https://github.com/soburi/xen/

Xen (Upstream)
https://xenbits.xen.org/git-http/xen.git

We can use the upstream as the source and edit from there.

Purpose

Externalizing MIT-licensed Xen public headers from https://github.com/zephyrproject-rtos/zephyr/tree/main/include/zephyr/xen/public.

Mode of Integration

As a module: proposed name xen or xen-public

Maintainership

@soburi

I would also like to ask @firscity, the maintainers of xen-related features, for their cooperation.

Pull Request

#91643

Description

Currently, the MIT-licensed Xen public headers have been incorporated
under the include/zephyr/xen/public.

However, the recent policy is not to include sources other than Apache-2 in the main tree.
I plan to add MIT files again this time, so I would like to make it an external module.

Security

There is no particular problem at present.

Dependencies

No dependencies.

Version or SHA

b26dba6182bc2d7a14c2278af45cd243db308ad8 (https://github.com/soburi/xen/)

License (SPDX)

MIT

[ifyall]

@soburi The upstream link provided in the Origin section doesn't work for me. I found this link, which I assume is correct: https://xenbits.xen.org/gitweb/?p=xen.git.

[soburi]

@ifyall

@soburi The upstream link provided in the Origin section doesn't work for me. I found this link, which I assume is correct: https://xenbits.xen.org/gitweb/?p=xen.git.

The URL you provided can be displayed in the browser, but it cannot clone it with git, so I am listing it with the current URL. (It is the URL written on the page you provided.)

[firscity]

Hi @soburi, thank you for contribution and sorry for late reply!

In general, we had the same idea some time ago and wanted to implement it, I will check your changes this week and will post my comments.

Best regards.

[carlescufi]

@soburi thanks for the proposal. Today we talked about this change in the TSC, and I mentioned this during the meeting: is this really worth it for a bunch of headers that are updated relatively infrequently? Sure, we would be removing some external headers from the main tree, but at a cost of yet another repo in our west.yml and a west update that becomes a bit slower.

[soburi]

@carlescufi

Checking other PRs, it seems that they are attempting to minimize the inclusion of code other than Apache-2.0 in the mainline as much as possible, so my primary objective is to follow this policy.
So, if it's permissible according to the policy, there's no problem with leaving it as it is.

However, the fact that I need to add files this time rejects the assumption that updates will continue to be infrequent in the future,
And since the code is not written according to the Zephyr coding standards, I think it would be better for maintenance purposes to externalize it if possible.

[nashif]

approved by the TSC