Re: [RFC] how to get real ifi_baudrate from network interface

On Thu, Sep 20, 2012 at 1:34 AM, Konstantin Belousov
<kostikbel_at_gmail.com> wrote:
> 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.

thanks. so, i take it there is no objections to the proposed hack-ish
workaround? i understand that there is a desire to fix thing "the
right way", but it involves breaking ABI. at least proposed hack-ish
workaround gets us somewhere. if no one objects, then i will put
workaround in.

thanks,
max