-
-
Notifications
You must be signed in to change notification settings - Fork 779
[Cursor Test] Remove PcComponent from of chips/
in favor of DefaultPeripherals
/ InterruptService
approach
#4583
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
base: master
Are you sure you want to change the base?
Conversation
This initial version is not mergable (uses arch-specific crates in components), but this is, I think, close, and it is a very needed change. |
chips/
and into boards/components
chips/
in favor of DefaultPeripherals
/ InterruptService
approach
I went ahead and asked Cursor to use the DefaultPeripherals / InterruptService approach instead, which I think is how we typically handle this sort of thing in other chips. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Cool!
This commit was primarily authored by Cursor (gpt-5). I used the following prompts: 1. This file contains a component, but Tock components are all supposed to be defined in the boards/ crate. Can you move the component defined in this file into the boards crate in a similar style to how other components are defined, and update boards/qemu_i486_q35/src/main.rs accordingly so that board still builds? 2. The component should go in the boards/components directory alongside other components. Can you move it there, in a file named x86_pc_component.rs? 3. Please do not call static_init!() within finalize(), instead move that into x86_pc_component_static. 4. Thank you. Can you also move serial_port_component_static!() into this component file? 5. Can you just inline the macro rather than having it be a standalone macro? Also, please be sure to delete it from its original location Next, I had Cursor remove PcComponent; use DefaultPeripherals / InterruptService approach 1. We do not want to include arch-specific crates in the components directory -- it does not make sense for arm boards to have dependencies on crates that only compile for x86. This is making me realize that components is actually not the right solution for this. Instead we should be splitting the initialization purely between the board crate and the chip crate, using something like Sam4lDefaultPeripherals and setup_circular_deps in chips/sam4l.rs. Can you pivot x86_q35_src/chip.rs to use this approach? 2. We cannot have the macro calling static_buf!() in chip.rs. Please put initialization of these peripherals in the board file, similar to how is done in board/imix/src/main.rs. Then update the board file to not use the component anymore, and remove the component. 3. Can you also port x86_q35 to use the interrupt_service trait and pattern, similar to sam4l? 4. Lets keep the panic if an unhandled interrupt arrives (by matching on the return value from service_interrupt). Also, lets not have both new() and new_with_peripherals -- just rename new_with_peripherals to new and inline the implementation of the original new() method into it. This includes some manual cleanup by me as well, including a bunch after a big rebase.
b2e8d70
to
78cf704
Compare
I rebased this and applied some more changes based on my own review. There were a lot of conflicts in the original with #4596 which made rebasing tricky, so I squashed all the original commits to make rebasing simpler. I did the rebase manually, not using Cursor, since it was tricky and I wanted to be sure I kept the spirit of #4596 . |
@reynoldsbd I would appreciate if you could take a look at this PR. This brings the x86 chip more in line with the rest of the Tock ecosystem and I think hopefully makes it even easier for your team to carry changes in your board file without having to modify the x86 chip file (you could even modify the DefaultPeripherals struct by just passing in your own version of it). This change will of course require you to mirror the modifications to the qemu board file in any downstream x86 board files you have |
@hudson-ayers perhaps the base for the PR is improper or something (it's not a PR against |
Thanks, I forgot this was originally targeting my other cursor PR (which I did not rebase). fixed! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I say we merge this. It fixes a reasonably substantial technical debt as we shouldn't have had static_init in chips in the first place.
@tock/x86-wg |
Pull Request Overview
This PR was entirely authored by Cursor (model: gpt-5). I intentionally did not make any edits to the generated code -- I wanted to use this as a brief exercise to see how capable cursor was of making a basic refactor. I picked the most recently opened issue. I did not review the changes in depth (yet), but made some suggestions in response to the initial changes. I gave the following 5 prompts to get it here:
This file contains a component, but Tock components are all supposed to be defined in the boards/ crate. Can you move the component defined in this file into the boards crate in a similar style to how other components are defined, and update boards/qemu_i486_q35/src/main.rs accordingly so that board still builds?
The component should go in the boards/components directory alongside other components. Can you move it there, in a file named x86_pc_component.rs?
Please do not call static_init!() within finalize(), instead move that into x86_pc_component_static.
Thank you. Can you also move serial_port_component_static!() into this component file?
Can you just inline the macro rather than having it be a standalone macro? Also, please be sure to delete it from its original location
Based on the reply from Brad, I then issued four additional prompts:
We do not want to include arch-specific crates in the components directory -- it does not make sense for arm boards to have dependencies on crates that only compile for x86. This is making me realize that components is actually not the right solution for this. Instead we should be splitting the initialization purely between the board crate and the chip crate, using something like Sam4lDefaultPeripherals and setup_circular_deps in chips/sam4l.rs. Can you pivot x86_q35_src/chip.rs to use this approach?
We cannot have the macro calling static_buf!() in chip.rs. Please put initialization of these peripherals in the board file, similar to how is done in board/imix/src/main.rs. Then update the board file to not use the component anymore, and remove the component.
Can you also port x86_q35 to use the interrupt_service trait and pattern, similar to sam4l?
Lets keep the panic if an unhandled interrupt arrives (by matching on the return value from service_interrupt). Also, lets not have both new() and new_with_peripherals -- just rename new_with_peripherals to new and inline the implementation of the original new() method into it.
Testing Strategy
This pull request has not been tested.
TODO or Help Wanted
This pull request still careful review and testing.
Documentation Updated
/docs
, or no updates are required.Formatting
make prepush
.