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? Michalis _______________________________________________ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
