Skip to content
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

Closed
dcpleung opened this issue Dec 3, 2019 · 8 comments
Closed

Request a new repository for the Xtensa HAL #21115

dcpleung opened this issue Dec 3, 2019 · 8 comments
Assignees
Labels
area: Xtensa Xtensa Architecture Feature Request A request for a new feature

Comments

@dcpleung
Copy link
Member

dcpleung commented Dec 3, 2019

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 (branch RF)

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.

@dcpleung dcpleung added the Feature Request A request for a new feature label Dec 3, 2019
@ulfalizer
Copy link
Collaborator

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 cp and Git branching ("so primitive"), when that's really the smoothest way to do things.

I don't think anyone has wished the Kconfig or devicetree code was in a different repo.

@ulfalizer
Copy link
Collaborator

Anyway, sorry for hijacking. Just probing a bit.~

@andrewboie
Copy link
Contributor

andrewboie commented Dec 3, 2019

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.

Would this apply to all HALs ?
You might want to talk to @mbolivar it seems like we have taken some pains to get all the HALs out of the main tree.

For one thing, it ensures that Coverity isn't flagging code we don't control.

@dcpleung
Copy link
Member Author

dcpleung commented Dec 3, 2019

@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". :)

@ulfalizer
Copy link
Collaborator

Would this apply to all HALs ?
You might want to talk to @mbolivar it seems like we have taken some pains to get all the HALs out of the main tree.

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.

For one thing, it ensures that Coverity isn't flagging code we don't control.

Maybe Coverity could be disabled for some directories.

@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).

Might need some way to hide some code, though I wonder if simple branching might be enough.

Well... at this point, I will just follow the "process". :)

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.

@aescolar aescolar added the area: Xtensa Xtensa Architecture label Dec 3, 2019
@aescolar
Copy link
Member

aescolar commented Dec 3, 2019

@nashif @MaureenHelm @carlescufi : One of you would need to create this new repo.

@carlescufi
Copy link
Member

@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

@dcpleung
Copy link
Member Author

dcpleung commented Dec 3, 2019

@carlescufi Thank you. :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: Xtensa Xtensa Architecture Feature Request A request for a new feature
Projects
None yet
Development

No branches or pull requests

7 participants