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. Kevin
