(Sorry for the duplicate reply -- I usually don't post to mailing lists from work so the mailer had the wrong settings) 2014-07-01 9:22 GMT-07:00 Michalis Pappas <mpappas@xxxxxxxxxxx>: > On 07/01/2014 04:27 PM, Ben Chan wrote: >> Except from the above, there is the issue I mentioned earlier about >> netlink. In particular, the driver defines a custom control interface >> based on ioctl and netlink. However their implementation has the >> following issues: >> >> - Uses on the SIOCDEVPRIVATE ioctl (obsolete). >> >> - Uses a custom netlink address (should be using netlink generic). >> >> - Uses a custom netlink event notification mechanism (should be using >> the one defined in net/wimax.h). >> >> - The implementation was only partially complete. Only a minor fraction >> of the FSM was implemented, and even that is actually broken. >> >> I put together a patch that removes the old interface and I am currently >> working on replacing it with the one defined in net/wimax.h. >> We'll probably need to do some testing on the actual hardware for this >> one, but I'll get back to you as soon as I have a better idea on the >> details. >> >> >> [Ben] The driver has a corresponding user-space library, which relies on >> the custom netlink and ioctl interface. The code can be found in the >> Chromium OS repo: >> https://chromium.googlesource.com/chromiumos/third_party/gdmwimax/+/master/. >> Changing the the driver interfaces can potentially break the user-space >> library, so I'd like to learn more about the changes you're proposing. >> Could you send me some work-in-progress patches? >> > > Hmm, I wasn't aware of the existence of the user-space library. From a > peek through the sources I notice some copyright disclaimers by GCT. How > do they distribute that library? Who is the maintainer? > > My proposal was to replace the custom interface with the kernel's > standard interface for controlling WiMax devices (see include/uapi/ and > include/net/wimax.h). > > In userspace, the interface is supported by wimaxtools' libwimaxll. See: > > https://github.com/ago/wimax-tools/ > > I understand now that this will cause modifications from your part. I > don't know whether the dont-break-userspace principle applies to drivers > in staging. Also, given the problems I stated earlier, I'm not that sure > if the driver in the current state will be accepted to the mainline. > > Maybe Greg could help us a bit here? I'm not Greg, but in general the requirements of not breaking the userspace ABI does not apply to staging drivers. However, that doesn't mean that it makes sense to gratuitously break it "just because". As Ben mentions, the "wimax-tools" isn't a generic tool, it's just a generic name for a tool for one other driver. Switching over to a generic netlink address seems reasonable. I'm less certain how much it's worth to polish it beyond that, especially given that there's already legacy tools out there that use the existing interface (changing the address shouldn't be nearly as big a deal to sort out than changing the whole ABI). It's not like WiMax is a bustling business category where we'll see a large number of new devices in the years to come. Chances are pretty good that the few we have now are all that there will be. -Olof _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
