Skip to content

Conversation

lschuermann
Copy link
Member

Pull Request Overview

This commit removes tock-register-interface from the kernel repository source tree. From this point onward, this subtree instead lives at https://github.com/tock/tock-register-interface. Revision b512f97e5eb5 of the tock-register-interface repository corresponds to this remove tree's contents, modulo added license headers, a CHANGELOG entry, and a logo for the repository.

This change is motivated (and based on) PR #4587, and implements a long-standing goal of maintaining tock-registers as a first-class crate with its own stability guarantees, separate from the kernel. It also follows in line with other kernel dependencies which we depend on for the Tock kernel, but maintain as part of the Tock GitHub organization, and thus retain full control over.

Testing Strategy

make prepush

TODO or Help Wanted

N/A

Documentation Updated

  • Updated the relevant files in /docs, or no updates are required.

Formatting

  • Ran make prepush.

tyler-potyondy and others added 2 commits September 9, 2025 12:00
The current method for including tock-registers is via the Cargo path
specifier. If an external crate A relies on tock-registers as a
dependency, using A in Tock will be flagged as a version mismatch (even
if both are in fact the same version) since Cargo believes the same
version crate to be different versions if one is specified as:
```
tock-registers = "0.10.0"
```

while the other is specified as:
```
tock-registers = { path = "path_to_tock_registers" } # also v0.10.0
```
This commit removes tock-register-interface from the kernel repository
source tree. From this point onward, this subtree instead lives at
https://github.com/tock/tock-register-interface. Revision b512f97e5eb5
of the tock-register-interface repository corresponds to this remove
tree's contents, modulo added license headers, a CHANGELOG entry, and
a logo for the repository.

This change is motivated (and based on) PR #4587, and
implements a long-standing goal of maintaining tock-registers as a
first-class crate with its own stability guarantees, separate from the
kernel. It also follows in line with other kernel dependencies which
we depend on for the Tock kernel, but maintain as part of the Tock
GitHub organization, and thus retain full control over.
@github-actions github-actions bot added kernel tock-libraries This affects libraries supported by the Tock project arch/risc-v RISC-V architecture labels Sep 9, 2025
@lschuermann lschuermann requested a review from ppannuto September 9, 2025 20:31
@brghena
Copy link
Contributor

brghena commented Sep 9, 2025

crates.io will need to be updated to point at the new repo. https://crates.io/crates/tock-registers

@lschuermann
Copy link
Member Author

lschuermann commented Sep 9, 2025

crates.io will need to be updated to point at the new repo. https://crates.io/crates/tock-registers

Good point, we should do that after merging, presumably.

Edit: actually, it might be that we cannot update this information standalone, as it is pulled out of the Cargo.toml. I will update that file in the tock-register-interface repo. But the metadata might be incorrect until we tag the next release.

@lschuermann
Copy link
Member Author

lschuermann commented Sep 9, 2025

While we're at it, should we resolve the inconsistency in calling it tock-register-interface in some, and tock-registers in other places? The crate is called tock-registers, but the repo is, and subdirectory was called tock-register-interface, which is unnecessarily inconsistent and confusing.

I propose we call everything tock-registers, as that's already used for the crate and changing that would be breaking. This seems like the exact right time to rename the repository, before anyone relies on it. @tock/core-wg (and in particular @ppannuto @brghena) thoughts?

Copy link
Contributor

@bradjc bradjc left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can't do this without updating our external dependencies policy as it does not permit external dependencies in crates like arch and chips.

@bradjc
Copy link
Contributor

bradjc commented Sep 9, 2025

I support standardizing on the name tock-registers.

@lschuermann
Copy link
Member Author

We can't do this without updating our external dependencies policy as it does not permit external dependencies in crates like arch and chips.

I thought that the (verbal) argument around https://github.com/tock/firmware/ was that we're more comfortable with "external" dependencies that are under our control, i.e., ones under the tock GitHub organization. But I acknowledge that was for dependencies of boards (and perhaps individual capsule-crates), and we'd need to codify this exception in the ExternalDependencies.md document. I can draft up a PR.

@lschuermann
Copy link
Member Author

@bradjc Another semantics question we haven't addressed in this document is what constitutes an "external dependency"? External to the kernel git repo? External to the Tock git org? Is depending on a crate maintained in the kernel repo, but pulled in using crates.io external? What about a crate in the Tock GitHub org, and depended upon with a git hash?

@lschuermann
Copy link
Member Author

lschuermann commented Sep 9, 2025

I support standardizing on the name tock-registers.

I have done the rename: https://github.com/tock/tock-registers
Nothing should have used or reference the old name, given that the old repository path contained very outdated code up until an ~hour ago.

@bradjc

This comment was marked as duplicate.

@ppannuto
Copy link
Member

ppannuto commented Sep 9, 2025

(edit) Discussion moved to #4589

@bradjc
Copy link
Contributor

bradjc commented Oct 2, 2025

We should add a link in the libraries readme to the new location.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

arch/risc-v RISC-V architecture kernel tock-libraries This affects libraries supported by the Tock project

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants