The reason why I would need this is as follow : One equipement begins to fail, and I receive frames with CRC errors The driver is able to watch it, not the application -> this is a problem. Then a maintenance process comes and must be able using the driver to run a diagnosis program.
use case 1: the recv function returns -1 the application checks /proc/rtnet/stats use case 2 : the application polls the nic status with an ioctl. Regards, S.Ancelot On 11/10/2012 08:26, Jan Kiszka wrote: > On 2012-10-11 08:23, Stéphane ANCELOT wrote: >> On 11/10/2012 06:56, Jan Kiszka wrote: >>> Regarding the drivers, the existing interface should be used (or >>> implemented where lacking yet). Regarding a userspace interface, we only >>> have /proc/rtnet/stats so far. Would that be sufficient for your use >>> case, or how does you userspace need to access the data? >> I would need a straight access to these data, it seems cleaner using an >> ioctl to poll it periodically , from the userspace app. >> >> I think this ioctl should be implemented in any RTNET driver. > Drivers don't expose RTDM devices. We only have RTDM sockets so far, you > should would have to add something similar to the netdevice(7) interface > of Linux (see man page). > > Jan > > ------------------------------------------------------------------------------ Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev _______________________________________________ RTnet-users mailing list RTnet-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rtnet-users
