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

Improving virtIO <-> sDDF interface #53

Closed
erichchan999 opened this issue Mar 27, 2024 · 2 comments · Fixed by #37
Closed

Improving virtIO <-> sDDF interface #53

erichchan999 opened this issue Mar 27, 2024 · 2 comments · Fixed by #37

Comments

@erichchan999
Copy link
Contributor

Currently each virtIO device class talks to the sDDF interface via the same sddf_handler struct, which has been made generic. Furthermore, we have each device initialised via the same function virtio_mmio_device_init, which takes in an enum that specifies the device class type.

However a better design would be to have:

  • different sddf_handler structs specific to each device class.
  • different init function for each device class.
@alexandermbrown
Copy link
Contributor

alexandermbrown commented Apr 24, 2024

Not too sure about the name "handler". I think "handler" came from "queue_handle" then for some reason we put an r on the end. E.g., the global array sddf_handler_t sddf_serial_handlers[SDDF_SERIAL_NUM_HANDLES] has NUM_HANDLES as the size, doesn't really make sense. All this needs to be is something like void *device_data, it doens't need to be sDDF specific.

I agree we should have a per device class init function. virtio_mmio_device_init doesn't really do much extra apart from register the exception handler and virq. We could either

  • remove virtio_mmio_device_init and put exception and virq registration in per-device functions, or
  • rename and switch sddf_handlers to be a device-specific struct passed with void *.
    • if we wanted to remove the switch statement we could also pass in the virtio_*_init function as a function pointer.

@alexandermbrown
Copy link
Contributor

FYI: I've made a draft of these changes in #37

@alexandermbrown alexandermbrown linked a pull request May 7, 2024 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants