Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 25 Feb 2015 14:42:16 -0800
From:      Eric Joyner <ricera10@gmail.com>
To:        Gleb Smirnoff <glebius@freebsd.org>
Cc:        "freebsd-net@freebsd.org" <freebsd-net@freebsd.org>, Jack Vogel <jfvogel@gmail.com>, Mike Karels <mike@karels.net>, "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org>
Subject:   Re: Adding new media types to if_media.h
Message-ID:  <CA%2Bb0zg-ANPQQUpUOg5iq5MTfTAuw7_jq=DtCeym6mDxpdPNm5w@mail.gmail.com>
In-Reply-To: <20150225222902.GD17947@glebius.int.ru>
References:  <BC6AB805-B699-438E-9EC6-015C005D6B1D@neville-neil.com> <201502170150.t1H1ouxM020621@mail.karels.net> <20150225221120.GC17947@FreeBSD.org> <CAFOYbc=Zw7S70d=rjTXdnfajM8cmbCNVH4QPfEBz=HkjRc0wMw@mail.gmail.com> <20150225222902.GD17947@glebius.int.ru>

next in thread | previous in thread | raw e-mail | index | archive | help
Tbh, I respect Gleb's approach, but developing such a thing would take a
while; the fix Mike proposed would be a fix now.

I mean, I'd like to see a decoupling of media types and speeds from
"standard" names, and maybe have both an ability to query what modules a
device supports and what speeds it supports given its current module,
instead of relying on the clunky media type list now. And then it'd be nice
to set flow control from ifconfig, too, without having to couple those
modes to media types. I'm still all for having a new system in the future.

But in changing the KPI so much, it'd be important to consider the "do we
need an ethtool-equivalent" discussion.

And I think we've lost a bunch of people who were in the original
discussion from the to:/cc: list.

---
- Eric Joyner

On Wed, Feb 25, 2015 at 2:29 PM, Gleb Smirnoff <glebius@freebsd.org> wrote:

> On Wed, Feb 25, 2015 at 02:17:44PM -0800, Jack Vogel wrote:
> J> So we have products coming soon that need to extend the media, if you
> have
> J> grandiose plans in the future you can worry about things then, Linux can
> J> handle the extended media TODAY, wouldn't it be nice to do so as well?
>
> I didn't suggest to wait, did I?
>
> J> Also, this solution is something that can be MFC'd into 10 STABLE,
> J> if you do something big in the 11 stream I will be that wont be
> possible,
> J> so I'd say lets do this as a first step.
>
> That would mean that new SIOCXGIFMEDIA needs to be supported from now and
> forever, still using the old structure and still limited to 62 types.
>
> Alternative is:
>
> In head:
>   - new if_media, new value for SIOCGIFMEDIA, old API preserved via
>     keeping oif_media, OSIOCGIFMEDIA, keeping it contained under
>     ifdef BURN_BRIDGES. With a possibility to remove it some foreseable
>     future.
>
> Merging to stable/10:
>   - new if_media by the name of nif_media, new SIOCGIFMEDIA by name of
>     NSIOCGIFMEDIA
>   - old API untouched
>
> This way we still are able to introduce new feature to stable/10. But
> the ugly compat code is put into the branch with limited lifetime,
> instead of carrying it to future.
>
> --
> Totus tuus, Glebius.
> _______________________________________________
> freebsd-arch@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-arch
> To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"
>



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CA%2Bb0zg-ANPQQUpUOg5iq5MTfTAuw7_jq=DtCeym6mDxpdPNm5w>