Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Conversation

Samir-Rashid
Copy link
Contributor

@Samir-Rashid Samir-Rashid commented Aug 13, 2023

Pull Request Overview

The driver liveliness check is defined in TRD104 4.3.1. I have updated all drivers in advance of Tock v3 (#3375). Make code comments and documentation consistent with regards to "driver existence check" terminology -- change as per #2908. "Driver check" falsely implies some sort of functionality checking.

Testing Strategy

Unsure how to test. These are breaking changes.

TODO or Help Wanted

There seems to be an established convention that command code 0 should return the number of things the driver is controlling. I moved those commands to the next available command code. Should these syscalls have some standardized code number?

Documentation Updated

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

Formatting

  • Ran make prepush.

@Samir-Rashid Samir-Rashid changed the title Enforce driver liveliness check capsules: enforce driver liveliness check Aug 13, 2023
@bradjc bradjc changed the title capsules: enforce driver liveliness check capsules: ensure driver existence check Aug 14, 2023
@bradjc
Copy link
Contributor

bradjc commented Aug 14, 2023

It's great that this is a comprehensive change because we do want cmd 0 to be a way to check if the driver exists. We don't want people starting from capsules that do not follow this convention so it's great to remove this broadly.

We can't change the cmd==0 for the drivers with a check in the "2.0" column here: https://github.com/tock/tock/blob/master/doc/syscalls/README.md As the comments indicate we can't change those until Tock 3.0.

For the others we can change, and I think we should.

Should these syscalls have some standardized code number?

I think generally using "1" would make sense, but I don't think it's worth changing existing drivers to match. Just adding them as the next available number makes sense to me for existing drivers.

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 break the stability guarantees.

@alevy
Copy link
Member

alevy commented Aug 17, 2023

@Samir-Rashid anything that is just a change in comments seems good. Anything that adapts the behavior of non-stable driver (as @bradjc suggests) is fine. In lieu of finality on #3375, I suggest removing any functional changes to the stable drivers from this PR and then we can basically merge almost immediately IMO.

As I noted in #3375 just now, it might be the best of all worlds to adapt TRD104 to allow these existing behaviors in the stable drivers, so those implementations may stay the same anyway (of course, that's just my stated opinion for now, not a conclusion).

@Samir-Rashid
Copy link
Contributor Author

As I reverted stable drivers, I noticed there is no PWM driver listed. It should be there as it has an allocated driver number 10 (in hex?).

@github-actions github-actions bot added the WG-OpenTitan In the purview of the OpenTitan working group. label Aug 17, 2023
@github-actions github-actions bot removed the WG-OpenTitan In the purview of the OpenTitan working group. label Aug 17, 2023
@hudson-ayers
Copy link
Contributor

As I reverted stable drivers, I noticed there is no PWM driver listed. It should be there as it has an allocated driver number 10 (in hex?).

Good catch, feel free to add that in this PR or another standalone one!

@Samir-Rashid
Copy link
Contributor Author

Apology for delay. Here is a diff of what I changed in case GitHub gets confused when I squash again. I made accompanying PRs tock/libtock-c#349 and tock/libtock-rs#517

@Samir-Rashid Samir-Rashid marked this pull request as ready for review October 3, 2023 07:22
Add driver liveliness checks as defined in TRD104 4.3.1.
Rename "driver check" to "driver existence check" as per tock#2908.
"Driver check" falsely implies some sort of functionality checking.

Note that stabilized capsules still need to be changed as noted in
the TODOs for the Tock 3.0 release.
Copy link
Member

@ppannuto ppannuto left a comment

Choose a reason for hiding this comment

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

I think this is looking pretty good. It's a lot of changes, but it's a nice consistency pass over a pretty old part of the kernel interface. It doesn't look like any stabilized interfaces are changed (though some of the documentation gets small updates in the name of consistency—which is good IMO).

@@ -55,7 +55,7 @@ the index of the last AC module.

**Returns**: `Ok(())` if starting interrupts was succesful.

* ### Command number: `4`
* ### Command number: `3`
Copy link
Member

Choose a reason for hiding this comment

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

Just noting for myself: this is not a change per se, but a fix of a documentation bug

@bradjc bradjc added this pull request to the merge queue Oct 9, 2023
Merged via the queue into tock:master with commit fe8ab65 Oct 9, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kernel WG-Network In the purview of the Network working group.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants