On Thu, Sep 20, 2012 at 06:15:54AM +0400, Gleb Smirnoff wrote: > On Wed, Sep 19, 2012 at 02:16:17PM -0700, Maksim Yevmenkin wrote: > M> hello, > M> > M> for sometime now i've been repeatedly annoyed by the fact that 10G > M> interfaces lie about their ifi_baudrate. i would like to propose > M> simple (hopefuly) change to address this. > M> > M> quick summary of the problem: > M> > M> struct if_data { > M> ... > M> u_char ifi_spare_char1; /* spare byte */ > M> u_char ifi_spare_char2; /* spare byte */ > M> ... > M> u_long ifi_baudrate; /* linespeed */ > M> ... > M> }; > M> > M> as you can see ifi_baudrate is an u_long which is an arch specific > M> type. on 32-bit arch it does not have enough bits to hold 10G line > M> speed value (in bits per second) > M> > M> proposal > M> > M> we reuse one of the ifi_spare_char1 or ifi_spare_char2 bytes and > M> re-purpose it as power factor to be applied to ifi_baudrate, i.e. > M> > M> real_ifi_baudrate = ifi_baudrate * 10 ** ifi_spare_char1 > M> > M> obviously, 10G nic drivers will have to set ifi_spare_char1 to > M> appropriate value, but it should not be a big deal. also, legacy tools > M> that do not know about ifi_spare_char1 would continue to report > M> "wrong" ifi_baudrate as they used to. > M> > M> any objections? > > IMO, this is way to go for stable branches. In head it'll be better just > have uint64_t without any crutches. You cannot do this in head either. It would break the libc exported ABI, at least for getifaddrs(3). At least, the compat shims need to be provided, but I suppose that breakage is much deeper.
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:30 UTC