On Fri, 2007-12-07 at 18:04 -0800, David Miller wrote: > From: Jean Tourrilhes <jt@xxxxxxxxxx> > Date: Fri, 7 Dec 2007 11:27:56 -0800 > > > > Can you explain a bit more about this patch? > > > > Those fields are defined and used in userspace, please check > > wireless.21.h in Wireless Tools. > > If you need auxiliary data in the userspace application, define > an auxiliary structure which references the thing you get back > from the kernel. > > I totally disagree with embedding things in kernel defined > interfaces that are purely userland internal data structures. > > You really need to clean up the way you handle the wireless > kernel APIs, it is getting worse not better and you really > do not use good judgment or good interface design practices > when you makes these changes. > > Everything is one big hack. > > I will seriously NACK wireless API changes like this until > the situation starts to improve. So how would _you_ add a scan capabilities bitfield (or a new generic capabilities bitfield) to the WEXT range call? We need the scan capability flag functionality; I don't care how we get it as long as the patch is not too invasive. But userspace needs to know what the driver can do, and the patch needs to be written so that drivers that don't have the capabilities don't need to be touched. Dan - 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
