You would not want to use the high priority work queue; that would
interfere with real time behavior. Nor would you want to use the low
priority work queue because that is used by most network drivers and so
would probably result in deadlocks.
Why no create your own dedicated kernel thread?
On 2/21/2021 11:49 AM, Fotis Panagiotopoulos wrote:
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 *
