> 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.
Oh, I wouldn't imagine that... That's bad. > Why no create your own dedicated kernel thread? Because I am quite short of RAM, and I wouldn't like to waste any memory in a thread's stack. I would prefer to somehow reuse RAM, as the workers do. Will a deadlock in LPWORK happen even if CONFIG_SCHED_LPNTHREADS == 1? Do I have any other way to poll the PHY? Στις Κυρ, 21 Φεβ 2021 στις 9:23 μ.μ., ο/η Gregory Nutt <spudan...@gmail.com> έγραψε: > 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 * > >>> > >>> > >>> > >>> > >
