On Thu, Jun 26, 2008 at 8:20 PM, Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote: > >> > 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? It liks to your series file, which is mostly unusable due to the NPUB patches. (When I wrote the post, there was an additional problem with the text that suggested that more than just that patch is needed.) Essentially, one has to patch the patch first. > >> 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 > Isn't it enough if we only put the patch in the wireless-testing kernel, and don't commit it to the mainline? Or maybe making it depend on BROKEN, like b43's NPHY support? What we are doing right now is essentially the same as if Buesch changed his experimental open-source b43 firmware to require editing the code and inserting a magic number to make it compile. I consider that to be quite different from an && BROKEN in the dependency list - and && BROKEN can be removed by someone who really wants to develop AP mode, while the current method requires finding the patch (because the link leads to a broken SERIES file.) -- Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-) -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
