On Sun, 2007-12-09 at 12:35 -0500, Dan Williams wrote: > 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. I'm happy to do the patch, just need to figure out how to do it within the constraints in a way that will be acceptable. - We could create another WEXT sub-ioctl (SIOCGIWCAPA ?) that would have all the capabilities together in a nice structure or something, but that was what GIWRANGE was supposed to be, and it would add yet another WEXT sub-ioctl. Still, if nobody is opposed to this, it would work nicely and would be a fresh start. (We can't have SIOCSIWSCAN return an error if you pass it options it doesn't know about, because that requires modifying _all_ drivers to return that error. We need to ensure that drivers that don't support the scan capabilities don't need changing, otherwise the field is useless because you can't tell whether a driver from 2.6.23 has the capability or not. It needs to be a _positive_ flag saying "yes I do support this" instead of drivers from, say, 2.6.23 silently accepting the command and not honoring the option) - Overload struct iw_range's enc_capa like I had originally proposed, perhaps changing the field's name to "capabilities" or something. However, there are only 32 bits available and we would already be using 11 bits in the field. Not too many. Jean was against this though. But if we changed the name/redefine it and maintain the current bit values it would only break stuff that checks for enc_capa != 0, which nothing should do because that check doesn't tell you anything at all. Do either of those sound better to you than extending struct iw_range? 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
