Date: Thu, 20 Sep 2012 08:07:57 -0700 From: Maksim Yevmenkin <maksim.yevmenkin@gmail.com> To: Konstantin Belousov <kostikbel@gmail.com> Cc: Gleb Smirnoff <glebius@freebsd.org>, Scott Long <scottl@freebsd.org>, FreeBSD Current <freebsd-current@freebsd.org> Subject: Re: [RFC] how to get real ifi_baudrate from network interface Message-ID: <CAFPOs6qgHTa3JW_z4L6XPdm5BhWrQVdFgeEuqyHLFCnk5fcNwg@mail.gmail.com> In-Reply-To: <20120920083409.GW37286@deviant.kiev.zoral.com.ua> References: <CAFPOs6oCot3Bt8S9KUoC-cELw5reP5jmwWnwxS21h=Zq3Q0d-A@mail.gmail.com> <20120920021554.GP85604@FreeBSD.org> <20120920083409.GW37286@deviant.kiev.zoral.com.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Sep 20, 2012 at 1:34 AM, Konstantin Belousov
<kostikbel@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAFPOs6qgHTa3JW_z4L6XPdm5BhWrQVdFgeEuqyHLFCnk5fcNwg>