Re: [PATCH v5 2/3] man/man2: introduce man page for file_getattr(2) syscall

[Alejandro Colomar <alx@kernel.org>]

[-- Attachment #1: Type: text/plain, Size: 2431 bytes --]

Hi Andrey,

> Date: 2026-10-22 10:43:08+0200
> From: Andrey Albershteyn <aalbersh@kernel.org>
>
[...]
> > Sorry that I missed this email.  I had an attack from a nation-state,
> > and had to be very careful with my hardware and communications.  I will
> > probably say something more detailed on the mailing list, but I'll only
> > share some details encrypted with very few people to not give too much
> > information that might help them.  Anyway, when I got back to normal, I
> > missed this and some other emails.
> 
> oh, sorry to here that, hope you're safe now

Yes, I am.  They infected my phone, but let me free after several hours,
and they couldn't infect my laptop as far as I could detect.  I got a
new phone, but luckily I didn't have to buy a new laptop.

> > And yes, this text seems good to me.  I see your new revision, so I'll
> > review that.  BTW, I wonder why there's this difference between
> > openat(2); was it on purpose?  
> 
> Not on purpose, but because file_getattr() uses newer
> filename_maybe_null() interface which works with a NULL.

Hmmmm.

> 
> > Should we maybe require that callers use
> > an empty string with file_getattr(2) too?
> 
> I don't have opinion on that, this could be done by dropping the
> 
> > > 	with the divergence that
> > > 	.I path
> > > 	can be NULL meaning an empty string.
> 
> then.

I'm worried about this, because people might experimentally realize
about the fact that NULL is accepted, and by saying that it behaves
exactly like openat(2), we might confuse them to think that openat(2)
also accepts it, so I think it's better to tell the truth.

> 
> > Or perhaps allow NULL in
> > openat(2)?  (I prefer the former.)
> 
> This, probably, would be not easy to change without any particular
> reason

I've been lately thinking that we should have an at(2) manual page that
describes the common features of all *at(2) syscalls.

I'll CC you and linux-api@ to discuss details about it, and know which
syscalls behave differently, because we should probably provide a
unified UX, and only deviate when there's a good reason.  Once such a
page exists, we could just refer to it in all *at(2) manual pages,
instead of repeating all the details every time.

But for this page, I'll take the text as is, I think.


Have a lovely day!
Alex

> 
> -- 
> - Andrey

-- 
<https://www.alejandro-colomar.es>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]