On Wed, May 28, 2008 at 09:30:29AM -0400, Pavel Roskin wrote: > The old ioctl was supporting bare 802.11, prism and AVS headers. I want > to replace all three of them with radiotap. I had to leave bare 802.11 > support for the AP interface (wlan0ap) for hostapd compatibility, but > the main interface should only support radiotap. > > Suppose we want to support the old ioctl. All three types of headers > that could be requested are going away now. Can we expect the software > that doesn't know of "iwconfig mode monitor" to know radiotap headers? > I don't think so. Where is this "are going away now" statement coming from? I see no technical reason for this apart from simplifying the implementation. > > this may break existing user space programs, I do not think this should > > go in. Obviously, same goes for removal of the actual use of this > > parameter and support for different header formats in patch 5/5. Adding > > support for radiotap format is of course reasonable, but I would be more > > careful with removing existing functionality which may still be in use. > > OK, if that's what you prefer, I can do it. I'm not strongly against replacing the old formats with radiotap, but I just do not follow the logic given as reasons for doing this as a simple replacement instead of doing it in steps (add radiotap now; remove deprecated formats later). I do not know how common user space programs that do not support radiotap, but would support one (or more) of the old formats (and similarly for the private ioctl vs. generic mode ioctl). If these kinds of cases are very rare, I could see better justification for simple replacement. If such programs are still in active use in systems that could be expected to upgrade to the new kernel version, there is much more justification to keep the old formats available and just make it clearer that they are deprecated and will be removed at a certain point in the future. -- Jouni Malinen PGP id EFC895FA -- 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
