Add the POSIX d_ino (file serial number) member to struct dirent and
populate it on every readdir() path, so portable callers (e.g. scp in
dropbear) that read dp->d_ino observe a meaningful, non-zero inode
number:
- include/dirent.h: declare d_ino in struct dirent and drop the
outdated comment claiming the field is unimplemented.
- include/nuttx/fs/hostfs.h: add d_ino to struct nuttx_dirent_s so
the hostfs ABI can carry the inode number across the VFS boundary.
- arch/sim/src/sim/posix/sim_hostfs.c: forward the host's
ent->d_ino into entry->d_ino.
- fs/vfs/fs_dir.c (read_pseudodir): copy the in-memory inode's
i_ino into entry->d_ino for the pseudo filesystem.
- fs/yaffs/yaffs_vfs.c: forward yaffs's dirent->d_ino into
entry->d_ino.
- fs/rpmsgfs: extend struct rpmsgfs_readdir_s with an 'ino' field
and propagate it across the RPC in both rpmsgfs_server (fills it
from the underlying entry) and rpmsgfs_client (writes it back to
the caller's nuttx_dirent_s).
Signed-off-by: Xiang Xiao <xiaoxiang@xiaomi.com>
A 16-bit ino_t can only address 65536 distinct file serial numbers,
which is not enough for filesystems with large directory trees and
breaks portable software (e.g. dropbear's scp) that expects a wider
inode number space. Widen ino_t (and nuttx_ino_t in the hostfs ABI)
to uint32_t to match common POSIX practice.
Update fs/rpmsgfs/rpmsgfs.h accordingly: promote the 'ino' field in
struct rpmsgfs_stat_priv_s from uint16_t to uint32_t and move 'nlink'
into the trailing 16-bit slot previously occupied by the reserved
field, keeping the overall packed-struct layout/size unchanged.
Signed-off-by: Xiang Xiao <xiaoxiang@xiaomi.com>
Add INIT message which can be used in case ns_announcement isn't
supported on the system.
It unlocks the client flow by calling rpmsg_post() on the semaphore.
Without this or an NS announcement, the client's semaphore will wait
forever.
This is practical when the server side is running from linux userspace
using ioctl where controlling NS announcements is problematic.
Signed-off-by: Andre Heinemans <andre.heinemans@nxp.com>
Most tools used for compliance and SBOM generation use SPDX identifiers
This change brings us a step closer to an easy SBOM generation.
Signed-off-by: Alin Jerpelea <alin.jerpelea@sony.com>