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
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
