RTEMS | iospace: Add iospace driver (!1243)

[Aaron Nyholm (@eagleirony)]

Aaron Nyholm commented on a discussion on cpukit/include/dev/io/iodev.h: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1243#note_151927

 > + *
 > + * @retval 0 Successful operation.
 > + * @retval non-zero Failed operation.
 > + */
 > +int rtems_iodev_unregister( const char *iodev_path );
 > +
 > +/**
 > + * @brief Destroys the iodev device. Frees the iodev if initialised with
 > + * rtems_iodev_alloc_and_init.
 > + *
 > + * This function must only be used on rtems_iodev instances that have not been
 > + * successfully registered with rtems_iodev_register.
 > + *
 > + * @param[in] iodev The iodev device.
 > + */
 > +void rtems_iodev_destroy_unregistered( rtems_iodev *iodev );

I did not go with this approach as there is afaik there is no why to know if the device has been destroyed or not. For example:
1. iodev is allocated and initalised with `rtems_iodev_alloc_and_init`
2. iodev is registered with `rtems_iodev_register`
3. iodev is unregistered (and destroyed) by `rtems_iodev_unregister`
4. `rtems_iodev_destroy_unregistered` is called

The pointer to the iodev passed into `rtems_iodev_destroy_unregistered` is now a pointer to freed memory.

`rtems_iodev_destroy_unregistered` makes it clear that it's only used to destroy unregistered iodevs. However, your issue remains with the lack of clarity of the API. I think renaming `rtems_iodev_unregister` to `rtems_iodev_unregister_and_destroy` would be a better solution to make it clearer what should be called in what order.

-- 
View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1243#note_151927
You're receiving this email because of your account on gitlab.rtems.org.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/bugs/attachments/20260605/caadbdd2/attachment-0001.htm>