LingaoM commented on PR #19369:
URL: https://github.com/apache/nuttx/pull/19369#issuecomment-4920800412
@xiaoxiang781216 Thanks for the review. I agree with the general design
rule here: sim applications should not call blocking host APIs directly,
because a blocking host call can block the whole simulated OS. I also agree
that the long-term upstream direction should be standard NuttX interfaces, not
application-visible host APIs.
The reason I did not simply switch everything to the existing standard
backends is that the current implementations do not fully cover this our use
case yet.
1. `usersock` is not currently enough for our transport set.
The current sim usersock backend only accepts `NUTTX_PF_INET`; other
domains return `-EINVAL`:
[sim_hostusrsock.c](https://github.com/apache/nuttx/blob/master/arch/sim/src/sim/posix/sim_hosthcisocket.c).
Our test transport needs more than IPv4/TCP. The local user channel
wrapper currently handles Bluetooth HCI, Unix domain sockets, and IPv4
But Unix-domain and HCI-style transports are not covered by the current
usersock implementation yet.
2. `sim_hosthcisocket.c` covers a different HCI use case.
The existing host HCI helper opens a host Bluetooth HCI user channel
with `socket(PF_BLUETOOTH, SOCK_RAW | SOCK_CLOEXEC | SOCK_NONBLOCK,
BTPROTO_HCI)` and binds it by `dev_idx`/
`HCI_CHANNEL_USER`:
[sim_hosthcisocket.c](https://github.com/apache/nuttx/blob/master/arch/sim/src/sim/posix/sim_hosthcisocket.c:188).
In our integration, that is a Unix-socket HCI transport, not only a
host `hciX` user-channel transport. I think the better upstream direction is to
extend the existing sim HCI/usersock infrastructure to support this transport,
rather than keeping a separate application-visible host socket API.
3. `hostfs` is the right standard interface for files, but file locking is
a real gap for this workload.
UnQLite uses POSIX advisory locks through `fcntl(F_GETLK)` and
`fcntl(F_SETLK)`:
In NuttX VFS, `F_SETLK` is converted into the private ioctl
`FIOC_SETLK`:
But hostfs currently forwards ioctl commands to `host_ioctl()` and only
special-cases `FIOC_FILEPATH`; it does not translate
`FIOC_SETLK/FIOC_GETLK/FIOC_SETLKW` back into host `fcntl()`
So I agree the application should use hostfs, but hostfs needs to
support the lock ioctl path correctly for UnQLite-style databases.
4. For epoll, I agree raw blocking host `epoll_wait()` should not be
exposed to applications.
Our local adapter avoids blocking by calling host `epoll_wait()` with
timeout `0` and then sleeping/yielding through the OS layer. However, I agree
this is not the ideal upstream interface. The better upstream design is either
to use NuttX poll/select/epoll on NuttX descriptors, or to keep any host
polling strictly inside a sim backend that never blocks the simulated OS.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
