Re: [PATCH v4 09/20] rust: io: use view types instead of addresses for `Io`

[Alexandre Courbot]

On Mon Jun 22, 2026 at 1:28 AM JST, Gary Guo wrote:
> On Sun Jun 21, 2026 at 5:15 PM BST, Danilo Krummrich wrote:
>> On Sun Jun 21, 2026 at 5:41 PM CEST, Gary Guo wrote:
>>> On Sun Jun 21, 2026 at 10:17 AM BST, Alexandre Courbot wrote:
>>>> As you can see, this lets a 32-bit access be done on the upper half of a
>>>> 64-bit register, which sounds like it should not be allowed? Similarly one
>>>> could change register types, and so on. This might not be "unsafe" in the
>>>> sense that it is still aligned and in bounds, but it lets the structure set
>>>> by the type system be bypassed. It could also potentially be a violation of
>>>> the hardware contract if the access width is relevant for this particular
>>>> address.
>>>
>>> I see no reason to prevent any of the case, this can be done by `try_cast()`
>>> API as well. If we need to take access width restriction and other
>>> restrictions into consideration, then a lot of API cannot be exposed at all.
>>> E.g. it is not okay to add `copy_read`/`copy_write` like the patch 19, because
>>> it uses memcpy_from/toio which is possibility doing byte-width access.
>>>
>>> in my opinion think people should be able to type casting without reaching out
>>> to `unsafe` if it's not UB. Similar to the logic on why we have `zerocopy`
>>> that allows casting between to types, these are "bypassing the typesystem" as
>>> well!
>>
>> I think this is fine as-is. The natural, ergonomic path through the API
>> (io_read!/io_write!/io_project! macros, IoLoc-based accessors, etc.) leads users
>> toward correct access widths.
>>
>> Whether through io_addr() or a custom IoLoc implementation, reinterpreting the
>> access type requires explicit, deliberate choices: picking a different type and
>> computing a byte offset. This is not something anyone would do by accident.
>>
>> So, as long as the API doesn't provide a subtle way to do the wrong thing by
>> accident, I don't think we need to add restrictions here.
>
> I'm still going to make this a standalone function to be used from `IoLoc`
> functions only, given these functions are not intended to be used by user
> directly anyway. But I'll leave `IoLoc` and `try_cast` as-is.

Yes, `io_addr*` look a bit out of place in the public API, and should be
easy to hide anyway. Using `IoLoc` to bypass the assigned type requires
a stronger intent, so as long as we are aware of the possibility and ok
with it, I have no objection to the current API.