Oliver, I'm going through your remarks, implementing those that we agree.
Yet, I'm not sure of 1 issue: On Wed, Feb 09, 2011 at 08:31:06PM +0100, Oliver Hartkopp wrote: > On 03.02.2011 10:39, Kurt Van Dijck wrote: > Dito. Here you already detected the problem by yourself :-) > > > + - /proc/sys/net/j1939/tp/retry_ms [int]: > > + Controls how many time to wait before retrying to send an individual TP > > + flow or data packet after transmission failure. > > Make it a constant that can be overridden via sockopt. > This (and maybe others, but let's stick to this one) property helps shaping the capabilities of the j1939 stack. Its goal is to help to get a balance between flexibility, performance, ... versus memory & cpu consumption. They are not only determined by the platform, but also on the bus that the system is connected to. Using ethernet/ip as equivalent, I see similarities with: $ ip link set eth0 promisc BOOL $ ip link set eth0 mtu VAL which are link properties that help the system administrator. These properties are now (for j1939) in /proc, since I just recently implemented netlink. I can understand not using /proc for these, but I still think these are 'link specific' properties (now they're global), and not socket specific. example: retry_ms : when replying an RTS with a CTS frame in a transport session, it's not clear yet _if_ a socket will be interested in the resulting packet when it's complete. If a retry is needed, the delay is IMO link specific. A constant is a bit rude I think, but I don't think this is a heavily used metric. Kurt _______________________________________________ Socketcan-core mailing list [email protected] https://lists.berlios.de/mailman/listinfo/socketcan-core
