> > Oh and I never answered to this. I disagree. Requiring people to patch > > their kernel for AP mode support is a good way to discourage > > "contributors" who don't even know how to compile a kernel, trust me, > > I've seen a fair share of private mails from those (which I ignore: do > > not mail me in private about AP support). > > > > Hence, I don't want to do it for exactly this reason: a bunch of dumb > > users will enable it either way, and actually _working_ on AP mode > > _will_ require kernel patches, so this isn't one that matters. > > The problem is that the location of the patch is extremely > non-obvious. Umm. The paragraph you're quoting: > "AP support requires mac80211 and nl80211 enhancements. In addition > to this you need external wireless-test.git patches from johill and > hostapd patches" (from the TODO-list) suggests that more than just the > "Allow AP/VLAN modes" patch is required to get any AP support actually links to the patch so what is your point? > Also, someone who can't patch a kernel likely also won't be able to > compile and use a git build of hostapd. IMO this provides enough > foolproofing. If we need more, then maybe add a secret and > undocumented (but clearly deducible from the code, not obfuscated) > parameter to hostapd, without which it refuses to handle nl80211-based > interfaces. The location of the patch can in no way be deduced from > the code. > > And, by the way, should we also require a patch for all experimental > drivers? I don't think so. You're missing the point. We do NOT want people to use mac80211's AP support UNLESS they also work on improving it. The "improving it" part REQUIRES patching the kernel. Hence, requiring patching the kernel to get AP mode support in the first place cannot be considered a hindrance. johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
