xiaoxiang781216 commented on PR #19369: URL: https://github.com/apache/nuttx/pull/19369#issuecomment-4923404127
> @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. it's better to improve usrsock infrastructure to allow forward more socket type to host. > 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. Yes, I think so. > 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()` Why not use NuttX file lock support? but want forward to host fs. Do you want the file lock work between NuttX simulator and the host apps? BTW, it plans to add file lock/unlock into mount_operation to support the hostfs/virtiofs/nfs usage. > 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]
