dirent.h: Add d_ino member to struct dirent

[tmedicci]

Summary

• dirent.h: Add d_ino member to struct dirent

This commit adds the d_ino member (ino_t type) to struct dirent to make it compatible with the POSIX definition of the structure.
According to https://pubs.opengroup.org/onlinepubs/9799919799/, the structure dirent shall include the following members:

ino_t  d_ino       File serial number.
char   d_name[]    Filename string of entry.

https://www.man7.org/linux/man-pages/man3/readdir.3.html also states that:

"
Only the fields d_name and (as an XSI extension) d_ino are
specified in POSIX.1. Other than Linux, the d_type field is
available mainly only on BSD systems. The remaining fields are
available on many, but not all systems.
"

Although d_ino isn't being used by NuttX directly, the structure dirent may be used by third-party applications and it's important
to have all the required members defined to avoid compatibility issues.

Impact

No direct impact for NuttX usage, but allows third-party apps to refer to the struct dirent's member correctly.

Testing

Internal CI testing + NuttX CI

[tmedicci]

Just tested locally and the CI error at https://github.com/apache/nuttx/actions/runs/12126636460/job/33809240627?pr=15023#step:7:126 happens on master (3a4b8ed). It doesn't seem to be related to this PR...

[yamt]

cf. #13556

if we add the field, i guess we should set a sane value.
at least it should be consistent with st_ino.

honestly speaking, i'm not sure if it's worth to implement d_ino for nuttx.
as the most filesystems here don't implement inode numbers at all,
applications using d_ino likely need modifications to deal with the situation anyway.

[Donny9]

The d_ino in the dirent structure and the st_ino in thestatstructure are both inode numbers, which are not supported by NuttX unless it has the capability, like Linux, to assign a unique inode to each file. When we internally adapt to third-party systems, we usually distinguish different files or directories by their filenames, rather than relying on st_dev and st_ino as in Linux.

[xiaoxiang781216]

some filesystem(nfs, hostfs, 9p etc) can really implement ino, so it make sense to add the basic support in vfs layer.
BTW, stat already include st_ino field, it's natural to add d_ino to dirent.

[yamt]

some filesystem(nfs, hostfs, 9p etc) can really implement ino, so it make sense to add the basic support in vfs layer. BTW, stat already include st_ino field, it's natural to add d_ino to dirent.

if you think it's useful, i don't object.
however, i'd suggest to actually implement it, instead of just adding a dummy field as this PR.

[xiaoxiang781216]

some filesystem(nfs, hostfs, 9p etc) can really implement ino, so it make sense to add the basic support in vfs layer. BTW, stat already include st_ino field, it's natural to add d_ino to dirent.

if you think it's useful, i don't object. however, i'd suggest to actually implement it, instead of just adding a dummy field as this PR.

Yes, we should zero this field for the unsupported file system and implement it at least for hostfs.

[tmedicci]

some filesystem(nfs, hostfs, 9p etc) can really implement ino, so it make sense to add the basic support in vfs layer. BTW, stat already include st_ino field, it's natural to add d_ino to dirent.

if you think it's useful, i don't object. however, i'd suggest to actually implement it, instead of just adding a dummy field as this PR.

Yes, we should zero this field for the unsupported file system and implement it at least for hostfs.

I proposed thir PR to enable building Python (apache/nuttx-apps#2879). I was able to make it work without it (same case of #13556), so this PR is not that necessary, although I might be able to work on it soon.