-
Notifications
You must be signed in to change notification settings - Fork 6.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Request a new repository for the Xtensa HAL #21115
Comments
I know this is "how it's done now" and that it's just a random change dutifully fitting into that scheme. I'm just jumping onto a random PR that seems somewhat tightly coupled to see if I have any supporters. I think it might be better to just copy it into the Zephyr repository if there'd be Zephyr-only changes. Then it can never drift out of sync with the Zephyr repository, and can be updated together with related Zephyr code in a single PR. There's a bunch of other advantages too, like useful Git history, seeing changes directly in PRs, and more people looking at the code in general. Just my two cents. It feels like we're adding layers of complexity as a knee-jerk reaction against some simple I don't think anyone has wished the Kconfig or devicetree code was in a different repo. |
Anyway, sorry for hijacking. Just probing a bit.~ |
Would this apply to all HALs ? For one thing, it ensures that Coverity isn't flagging code we don't control. |
@ulfalizer Personally, I like the beauty of having everything in one repo. Like you said, it would have usable git history, and all changes in PRs. Though, I understand the need to factor out the HALs. For example, companies probably need to vet the code before releasing products. With modules, they can pull in the ones really needed (kind of a moot point until west can pull in individual modules instead of all). Well... at this point, I will just follow the "process". :) |
I think it'd be easier at least for the ones that can be public. I suspect it won't happen in the short term anyway though. I just threw it out there on the off chance that someone might agree.
Maybe Coverity could be disabled for some directories.
Might need some way to hide some code, though I wonder if simple branching might be enough.
Yeah, I don't expect it to change soon. Just had some pretty awkward experiences with syncing up deps recently, and got curious if it was just me. Anyway, you know where I stand. |
@nashif @MaureenHelm @carlescufi : One of you would need to create this new repo. |
@dcpleung I prefer single repos too, but there were just too many issues with that in the context of Zephyr. Repo created: https://github.com/zephyrproject-rtos/hal_xtensa |
@carlescufi Thank you. :) |
The new repo will contain the Xtensa HAL, and will be included as a module via west.
Name of repo:
hal_xtensa
Upstream:
https://github.com/foss-xtensa/xtensa-hal
(branchRF
)It would be great if a
zephyr
branch is created to host Zephyr only changes.More details:
Currently we build the HAL together with the SDK from upstream source. By having it as a module, the HAL will be built as part of the app. This will allow us to update the HAL more often than SDK builds.
The text was updated successfully, but these errors were encountered: