Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 08 Feb 2015 20:49:18 -0600
From:      Mike Karels <mike@karels.net>
To:        Alfred Perlstein <alfred@freebsd.org>
Cc:        Adrian Chadd <adrian@freebsd.org>, Rui Paulo <rpaulo@me.com>, "freebsd-net@freebsd.org" <freebsd-net@freebsd.org>, Eric Joyner <erj@erj.cc>, John Baldwin <john@baldwin.cx>, Jack Vogel <jfvogel@gmail.com>, "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org>
Subject:   Re: Fwd: Adding new media types to if_media.h
Message-ID:  <201502090249.t192nI96091798@mail.karels.net>
In-Reply-To: Your message of Sun, 08 Feb 2015 16:56:49 -0800. <54D805D1.4050008@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
Alfred wrote:
> On 2/8/15 2:41 PM, Mike Karels wrote:
> >
> > To solve the second problem, I think the right approach would be to reduce
> > this interface to a truly generic one, such as media type (e.g. Ethernet),
> > generic flags, and perhaps generic status.  Then there should be a separate
> > media-specific interface for each type, such as Ethernet and 802.11.  To a
> > small extent, we already have that.  Solving the second, more general problem,
> > requires a whole new driver KPI that will require surgery to every driver,
> > which is not an exercise that I would consider.
> >
> >
> > I am willing to do a prototype for -current for evaluation.
> >
> > Comments, alternatives, ?
> Mike,

> I think we have enough people to chip in that your concern about 
> breaking the KPI is not as bad as you think.

> Would like to hear the first correct + long term + less hackish proposal 
> first.

> Norse has a kernel team that is heavily invested in networking that can 
> help with the transition.

> If done right, likely renaming ALL of the macros it will be quite 
> trivial to catch all bad cases and move us forward in one great leap.

Don't forget that the KPI is not the only part.  Breaking the user-level
interface (API/ABI are almost the same) gets into ports and other important
software that is harder to change.  A new KPI could still provide a compatible
API, but would be much constrained.  And fwiw, I don't see the advantage to
be gained unless the 802.11 software would be much improved.  I'm not the
one to weigh in on that.

		Mike



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201502090249.t192nI96091798>