Name and design

[AsakuraMizu]

Name

To be honest, I don't quite like this name since it's a bit confusing. What we are actually doing is "checking and accessing the user address space", which is not simply summarized by "ptr". At least it should include a "u" to indicate that what we're doing is related to user space, right?

I thought of a name like axuaccess, inspired by uaccess.h in the Linux source code, but this name combined with the preceding "ax" is too ugly. axuptr might be better, but not much better. axuser is a bit too broad. Maybe axuspace?

Anyway, it's not too important. Let me share some thoughts about design.

Current design

I don't see the need to depend on arceos crates in this repo. axhal::paging::MappingFlags is just an alias to page_table_multiarch::MappingFlags, and we don't actually need a AddrSpace type. Use the trait provider to provide check_region_access and populate_area may be better. Or even directly providing check_region depending on design.

As for the pointer wrapper types, I have also made some changes at https://github.com/AsakuraMizu/starry-next/blob/next/api/src/ptr.rs, including nullable! macro and nested ptr like UserConstPtr<UserConstPtr<c_char>> for the argv and envp args of sys_execve. Maybe you can adopt it.

Future design

Upstream ArceOS is going to refactor axmm via aspace_generic. I guess we can promote this crate to a user address space designed on top of aspace_generic so maybe we can have better solutions for the copying and clearing kernel paging space issue?

[AsakuraMizu]

Do we actually need a pointer wrapper type? I mean, maybe we could design a trait PtrExt or something like that, and then impl this trait for types like *const T?

I thought of this because as we use it now, we gradually find that this wrapper is not easy to use. For example, UserConstPtr<UserConstPtr<c_char>> is really not elegant compared to *const *const c_char. For another example, we may encounter a situation where the structures passed from the user, such as iovec, contains a pointer. To handle it, we must first cast the pointer to an address and then turn it into our wrapper, which is very inconvenient.

I'll put my envisioned design in a new branch, maybe sooner or later.

[Azure-stars]

Do we actually need a pointer wrapper type? I mean, maybe we could design a trait PtrExt or something like that, and then impl this trait for types like *const T?

I thought of this because as we use it now, we gradually find that this wrapper is not easy to use. For example, UserConstPtr<UserConstPtr<c_char>> is really not elegant compared to *const *const c_char. For another example, we may encounter a situation where the structures passed from the user, such as iovec, contains a pointer. To handle it, we must first cast the pointer to an address and then turn it into our wrapper, which is very inconvenient.

I'll put my envisioned design in a new branch, maybe sooner or later.

I favor using traits rather than encapsulating them as structs to handle user address space access because it reduces overhead and code redundancy.

[Azure-stars]

Future design

Upstream ArceOS is going to refactor axmm via aspace_generic. I guess we can promote this crate to a user address space designed on top of aspace_generic so maybe we can have better solutions for the copying and clearing kernel paging space issue?

Regarding axuspace, I think it is feasible to conveniently manage resources related to user-mode address space and provide convenient inspection and access methods.

In addition, if this module is possible, it is better not to only focus on posix interfaces, but to return some general information and provide posix compatibility.