Hi,
On Tue, Oct 22, 2024 at 02:34:09PM +0200, Kevin Brodsky wrote:
On 21/10/2024 15:43, Dave Martin wrote:
On Mon, Oct 21, 2024 at 12:06:07PM +0200, Kevin Brodsky wrote:
On 17/10/2024 17:53, Dave Martin wrote:
[...]
+/*
- Save the unpriv access state into ua_state and reset it to disable any
- restrictions.
- */
+static void save_reset_unpriv_access_state(struct unpriv_access_state *ua_state)
Would _user_ be more consistent naming than _unpriv_ ?
I did ponder on the naming. I considered user_access/uaccess instead of unpriv_access, but my concern is that it might imply that only uaccess is concerned, while in reality loads/stores that userspace itself executes are impacted too. I thought using the "unpriv" terminology from the Arm ARM (used for stage 1 permissions) might avoid such misunderstanding. I'm interested to hear opinions on this, maybe accuracy sacrifices readability.
"user_access" seemed natural to me: it parses equally as "[user access]" (i.e., uaccess) and "[user] access" (i.e., access by, to, or on behalf of user(space)).
Introducing an architectural term when there is already a generic OS and Linux kernel term that means the right thing seemed not to improve readability, but I guess it's a matter of opinion.
Both good points. "user_access" seems to strike the right balance, plus it's slightly shorter. Will switch to that naming in v2.
Suits me (wasn't sure I was going to win that one actually!)
Cheers ---Dave