Re: [rfc] removing the NDISulator

On 23 October 2013 10:40, Allan Jude <freebsd_at_allanjude.com> wrote:


> I think the point Adrian is trying to make, is that the NDISulator needs
> a maintainer, and rather than someone working on that hack, that person
> should spend their time on native drivers.
>

It's partially that.

It's also that a lot of the stuff the ndisulator provides (ie, all the
other devices we don't have drivers or stable drivers for) removes the
actual requirement that we _do_ get drivers written and new stack features
implemented. It lowers the barrier so far that quite honestly, I'm worried
that it won't attract new developers over to hack on wifi/ethernet drivers
or on the wifi stack itself.

(Except for Kevin Lo and if_rt. Thanks! And Cedric for iwn changes, thanks
again!)

There were plenty of people who were running the ndisulator to get 11n
support for atheros/intel chips until I and Bernhard came along. The actual
size of 11n work required in net80211 wasn't that great. It required
Bernhard sit down with the standard and a packet sniffer, ask the right
questions and have a few "wtf!" moments.

We have things like 11ac that are here right now and noone has stepped up
to hack on it. I've had a few people ask about whether we can run the
latest broadcom/atheros windows drivers under the ndisulator so they can
get 11ac support. This is another short-term crutch that gets a handful of
users online but it doesn't improve the overall FreeBSD wireless support or
enhance the features that we can support across multiple vendors.

In essence, I think the ndisulator is preventing us from biting the hard
problems now so we can actually grow the FreeBSD wireless ecosystem.

As someone earlier in the thread pointed out, it doesn't seem that many
> drivers are NDISulatable anymore.
>
> The proposal is to remove it from 11 (2 years away).
>
> I am all for keeping it, if it works, but if it is unmaintained, what
> state will it be in 2 years from now?
>

My proposal is to deprecate it now so people realise that we either need
the existing drivers fixed up or their existing/upcoming hardware plainly
won't be supported. Now, this may end us up with a bunch of hardware that
stops working. I'm treating this mostly like the GIANT device rototill - we
either care enough as a community to do what's necessary to fix up /
implement drivers, or we just cut them loose. But I'd rather see us do that
over extending it to include the latest NDIS wireless interfaces required
in Windows 7 and later. I believe by doing that, we're seriously hampering
our ability to grow the wireless side of things over the next five or so
years (ie the current specification lifecycle.) That worries me.

Thanks,



-adrian