Date: Thu, 13 Jan 2022 21:12:51 +0000 (UTC)
From: RVP <r...@sdf.org>
Message-ID: <c6445584-c6b2-55d6-4ea6-fc28d858e...@sdf.org>
| The patch is for processes to know that stat() will have to be
| called for that particular dirent.
Yes, I understood the patch. But why?
| DT_REG would not be right there.
Not always. No. But if the fd refers to a regular file,
it would be, right?
| (I've done this myself: call stat() if dirent.d_type is DT_UNKNOWN;
| otherwise, take dirent.d_type as valid and save a syscall.)
Sure, d_type is an optimisation. Since procfs knows what types
of files it has -- either it is creating them, or they come from
an open fd, which has a known type -- why not implement the
optimisation?
| A note in dirent.3 that procfs (and some others?) will always return
| DT_UNKNOWN would be a good idea, I think.
DT_UNKNOWN is intended for filesystems with directories that do not
maintain the d_type field, and so would need to fetch the inode (or
its equivalent) to supply the type - which would be relatively harmless
when the application follows the readdir with a stat on each entry,
but is needless overhead when the application does not care.
If procfs is not setting d_type correctly, that should be fixed.
(Which does not mean setting the type to unknown, when it is known.)
If your patch makes any difference to the way ls /proc/self/fd
works, that is just a fluke (relates to the way ls happens to
sequence its operations) and in no way any kind of general fix.
kre
