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
