Thank you very much! The interface psock_* seems good.
However, I need it to be called periodically. board_timerhook and watchdogs cannot call this interface. I guess, a work queue is my only option for this task? Στις Σάβ, 20 Φεβ 2021 στις 9:07 μ.μ., ο/η Grr <gebbe...@gmail.com> έγραψε: > When is using internal OS interfaces from another OS subsystem (or an app) > OK and not modularity rape? > > For example (and following my development line), if a SPI peripheral driver > needs to access GPIO data structure in order to control chip select, is it > more problematic than an app talking directly to a PHY or less? > > El sáb, 20 feb 2021 a las 12:30, Gregory Nutt (<spudan...@gmail.com>) > escribió: > > > > > > I suggested using file_open() and file_ioctl() in a previous email. > > > That is wrong. file_ioctl() cannot be used to access > > > socket_ioctls(). You would have to use psock_ioctl(). > > > > Because the socket interface goes though the network, there are some > > hand shakes and interlocks to prevent network activity while accessing > > the PHY interface. I think using a custom interface would be > > problematic. It would be best to use the internal OS socket interfaces > > directly. They prototyped and described in include/nuttx/net/net.h. > > For example, instead of using socket() you would use psock_socket(), > > instead of using bind(), you would use psock_bind(), instead of using > > ioctl(), you would use psock_ioctl(). > > > > The APIs are the same as the user space APIs exception that: (1) the > > are prefaced with psock_ and (2) the do not use an int socket > > descriptor. Rather, they use a pointer to the internal socket structure > > struct socket * > > > > > > > > >
