Hi, > >>>>> > >>>>> 2. If some station stop responding (stop sending a heartbeats), is > >>>>> there a way to inform a application that some station is down? Or that > >>>>> the station is up? > >>>> > >>>> The information is exported via /proc on both client and server. Unless > >>>> I forget something, there is no event signaling mechanism to wait on > >>>> such an error via the rtcfg tool, e.g. But that would be implementable > >>>> if required. > >>> > >>> Do you have something special in mind. This information is present in the > >>> system, the only problem is to export it to application. If you don't > >>> mind I could try to take care of it, with a little help from your side. > >> > >> Well, there could be something like "rtcfg <dev> monitor > >> [event,event,...]" with one event being "node-failure". Then you will > >> need to define and implement a corresponding RTcfg-config IOCTL that > >> implements the actual blocking of the caller and its wakeup on the > >> specified events in the kernel. The return code of the IOCTL or some > >> additional data structure could provide information about the event that > >> caused a wakeup. Well, that's a first, rough description if such an > >> interface. What would be important is to match it against an actual use > >> case, i.e. some script or application that will actually call "rtcfg > >> monitor". Otherwise, we risk designing something that no one would use > >> in the end. What do you have in mind here? > > > > I though rather about application api (xenomai native, posix). So, in the > > first step, I should implement ioctl blocking service and something like > > event-info structure. Then I prepare example containing relevant use case. > > The "rtcfg <dev> monito [event,event,...]" is last on my TODO list. What do > > you think about it? > > Keep in mind that the whole RTcfg implementation in RTnet is > conceptually non-RT. Thus, providing interfaces to real-time skins that > differ from those IOCTLs that also the command line tool uses makes > little sense. >
In this case, I agree that it does not make sense to implement a RT API. So I will follow a concept of the RTcfg implementation, and implement a event IOCTLs in accordance with other such system calls. Now, I am thinking about example, I see to options: - one rt app that create a two rt thread which one of them is blocked on non-rt IOCTL system call, - two application: a rt app doing something, a non-rt app monitoring events (sending info to a rt app through a pipe). What do you think? I assume, that rt applications are a control related applications that handle also communication issues. In this case we have to deliver a station down/up information to them somehow. Mariusz ------------------------------------------------------------------------------ This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev _______________________________________________ RTnet-users mailing list RTnet-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rtnet-users
