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 * > > > >
