Hi Wolfgang, On Mon, Feb 21, 2011 at 12:47:31PM +0100, Wolfgang Grandegger wrote: > Hi Kurt, > > 1) > >>>> can_stats->bus_errors++; > >>>> stats->rx_errors++; > > > > I believe these 2 structs have overlapping semantics, in the way that > > some bus_errors are rx_errors, but not all (as Wolfgang explained). > > Yes, of course. If you look how most kernel drives handle RX errors you > will realized that "rx_errors" is the *sum* of the individual errors. > Anyway, the main reason why we may want to keep "rx_errors" is to make > the user aware of those, especially when he is looking to the output of > ifconfig. Ok, makes sense now to me. So, we keep rx_errors, and increment them properly? and maybe increment tx_errors? [ rewinding my stack ...] Is bus_errors then needed? CAN defines a lot more bus_errors, but I outside the lab, counting error_frames is the only measure I've taken yet. And if one is really interested, catching each individual problem from a CAN socket is possible with CAN_RAW_ERR_FILTER sockopt.
> [...] > > a) replace can_stats->arbitration_lost with stats->collisions > > b) drop can_stats->bus_errors, use appropriate stats->XXX like > > stats->tx_aborted_errors > > stats->tx_carrier_errors > > stats->rx_crc_errors > > stats->rx_frame_errors > > Please *no* magic mappings. That will really confuse users. Only > rx_crc_errors and rx_over_errors could be used for the CAN stats. ok, I can live with that for the 'b)' part. Not sure whether you think 'arbitration_lost' and 'collisions' is *magic* mapping. I think that a collision on CAN, by its 'collision avoid' nature, equals an arbitration_lost. Just my opinion ... > Regards, Kurt _______________________________________________ Socketcan-core mailing list [email protected] https://lists.berlios.de/mailman/listinfo/socketcan-core
