On Tue, 2011-04-05 at 15:04 -0700, Javier Cardona wrote: > > After thinking about this more, yes, I think I do object. Not only is > > the design strange with passing frames back and forth, but also it seems > > like a rather slippery slope, at some point I fear somebody will attempt > > to "fake" MPM to take advantage of that kernel code even when it's not > > really fitting. > > The above seem to be concerns with the API itself and not with > partitioning. We could make the API specific for mesh peering frames > in a way that cannot be used for any other purpose other than > protecting mesh peering frames. Well, it's a bit of both. I can just see somebody trying to implement a new protocol and making it look like MPM in order to be able to feed it back into the kernel, or something like that. More generally, I don't much like the looping back of things. > I know of a few mesh use cases where wpa_supplicant is not required, > such as resource constrained embedded platforms like the ones used in > sensor networks. But hey, we'll re-evaluate the wpa_supplicant route > and see if it is doable. I think in that case it'd make some sense to make the code in the kernel configurable? Can't be all that much overhead to have essentially the same code outside the kernel? johannes -- 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
