So may be do not expose ptraddr_t yet, until it is finalized? If they choose (slightly) different semantic, we would have a huge problem.

In D53817#1229542, @kib wrote:

So may be do not expose ptraddr_t yet, until it is finalized? If they choose (slightly) different semantic, we would have a huge problem.

I don't find that option very palatable. I suppose we could use __ptraddr_t everywhere, but then we'd face considerable churn later (CheriBSD has over 500 lines containing ptraddr_t.)

The only question the first committee to review it had was: what type should subtraction produce so I don't anticipate semantic change (and any should happen well before 16.0).

How should ptraddr_t and vm_offset_t coexist? Are they semantically different, or should we gradually replace uses of vm_offset_t with ptraddr_t, or?

In D53817#1229561, @markj wrote:

How should ptraddr_t and vm_offset_t coexist? Are they semantically different, or should we gradually replace uses of vm_offset_t with ptraddr_t, or?

Right now vm_offset_t is inconsistent and sometimes equivalent to a ptraddr_t and sometimes to a uintptr_t. In CheriBSD we've converted a significant number of vm_offset_t's to a new vm_pointer_t because we need provenance preservation. I think @jhb wants to convert many of those into void *, but I'm a little unclear on the overalls scope. @alfredo.mazzinghi_cl.cam.ac.uk thinks we do end up with vm_pointer_t at least for a while as too much math is done on those for using void * to be comfortable.

D53818 actually does redefine vm_offset_t to ptraddr_t which isn't quite right, but will be once I extract the vm_pointer_t patches.

There's a bigger long term question if vm_foo_t should exist at all. I don't have a strong opinion there.

In D53817#1229564, @brooks wrote:

In D53817#1229561, @markj wrote:

How should ptraddr_t and vm_offset_t coexist? Are they semantically different, or should we gradually replace uses of vm_offset_t with ptraddr_t, or?

Right now vm_offset_t is inconsistent and sometimes equivalent to a ptraddr_t and sometimes to a uintptr_t. In CheriBSD we've converted a significant number of vm_offset_t's to a new vm_pointer_t because we need provenance preservation. I think @jhb wants to convert many of those into void *, but I'm a little unclear on the overalls scope. @alfredo.mazzinghi_cl.cam.ac.uk thinks we do end up with vm_pointer_t at least for a while as too much math is done on those for using void * to be comfortable.

Should we just use uintptr_t instead of vm_pointer_t? That is, do we have vm_pointer_t just to keep consistency in the Mach VM code? (That's fine if so, I just want to make sure I understand.)

D53818 actually does redefine vm_offset_t to ptraddr_t which isn't quite right, but will be once I extract the vm_pointer_t patches.

There's a bigger long term question if vm_foo_t should exist at all. I don't have a strong opinion there.

Me neither, but it's a lot of churn to remove at least vm_offset_t. vm_paddr_t and vm_pindex_t have no obvious substitute. vm_ooffset_t would have to be uint64ptr_t I think.

In D53817#1229564, @brooks wrote:

In D53817#1229561, @markj wrote:

How should ptraddr_t and vm_offset_t coexist? Are they semantically different, or should we gradually replace uses of vm_offset_t with ptraddr_t, or?

Right now vm_offset_t is inconsistent and sometimes equivalent to a ptraddr_t and sometimes to a uintptr_t. In CheriBSD we've converted a significant number of vm_offset_t's to a new vm_pointer_t because we need provenance preservation. I think @jhb wants to convert many of those into void *, but I'm a little unclear on the overalls scope. @alfredo.mazzinghi_cl.cam.ac.uk thinks we do end up with vm_pointer_t at least for a while as too much math is done on those for using void * to be comfortable.

D53818 actually does redefine vm_offset_t to ptraddr_t which isn't quite right, but will be once I extract the vm_pointer_t patches.

There's a bigger long term question if vm_foo_t should exist at all. I don't have a strong opinion there.

Originally, I introduced vm_pointer_t before ptraddr_t was a thing, with the intention of keeping symmetry with the existing Mach VM types, so vm_pointer_t was intended to replace cases where vm_offset_t was conflating a provenance-bearing pointer instead of an address. In general, I think that vm_offset_t should take the semantic of an address and in my mind it is equivalent to ptraddr_t, while vm_pointer_t is equivalent to uintptr_t.
I kept the naming separate only to align to the existing convention. In principle, I don't have an objection to replace vm_offset_t to ptraddr_t and vm_pointer_t to uintptr_t, but this would generate a lot of churn.

In D53817#1229572, @markj wrote:

In D53817#1229564, @brooks wrote:

D53818 actually does redefine vm_offset_t to ptraddr_t which isn't quite right, but will be once I extract the vm_pointer_t patches.

There's a bigger long term question if vm_foo_t should exist at all. I don't have a strong opinion there.

Me neither, but it's a lot of churn to remove at least vm_offset_t. vm_paddr_t and vm_pindex_t have no obvious substitute. vm_ooffset_t would have to be uint64ptr_t I think.

vm_ooffset_t is still uint64_t in CheriBSD. Why would it need to preserve provenance?

In D53817#1230450, @jrtc27 wrote:

In D53817#1229572, @markj wrote:

In D53817#1229564, @brooks wrote:

D53818 actually does redefine vm_offset_t to ptraddr_t which isn't quite right, but will be once I extract the vm_pointer_t patches.

There's a bigger long term question if vm_foo_t should exist at all. I don't have a strong opinion there.

Me neither, but it's a lot of churn to remove at least vm_offset_t. vm_paddr_t and vm_pindex_t have no obvious substitute. vm_ooffset_t would have to be uint64ptr_t I think.

vm_ooffset_t is still uint64_t in CheriBSD. Why would it need to preserve provenance?

In general it shouldn't, but I wasn't confident that we don't have code which assumes otherwise. I forgot to check what CheriBSD does--if vm_ooffset_t can just be uint64_t, then that's better.