On Thu, 2008-12-04 at 08:12 +0200, juuso.oikarinen@xxxxxxxxx wrote: > > >-----Original Message----- > >From: ext Dan Williams [mailto:dcbw@xxxxxxxxxx] > >Sent: 4. joulukuuta 2008 0:40 > >> > >> Hello, > >> > >> Some time ago, a colleague of mine, Luciano Coelho, opened a > >> discussion with this same subject. I think it is time now for me to > >> continue that discussion, because our aim, like that of > >Intel's, is to > >> achieve a unified WiMAX driver interface for Linux. For > >reference, the > >> original posting is archived in > >> http://linuxwimax.org/pipermail/wimax/2008-June/000028.html. > >> > >> As Luca explains in his e-mail, the Nokia architechture is different > >> from the approach taken by Intel. > >> - The Nokia architechture places the device independent WiMAX > >> interface at the kernel/user-space barrier, so that all user-space > >> components are independent of the WiMAX device. > >> > >> - The Intel architechture places the device independent WiMAX > >> interface on top of a user-space library, so that in the > >> kernel/user-space barrier, essentially, chipset specific > >messages are > >> exchanged. > >> > >> In the original posting, Luciano stated that the Nokia > >driver sources > >> are not publicized yet. This has now changed. For reference, please > >> see the Maemo.org repository at > >> > >http://repository.maemo.org/pool/maemo4.1/free/k/kernel-source-diablo/ > >> > >> The Nokia driver currently implements the WiMAX methods as private > >> extensions to the WLAN wireless events interface. Obviously, for a > >> long term solution fixed messages would need to be defined. > >Still, the > > > >Yeah, that's not going to work upstream, which is where we > >eventually want this to go... I think a fusion of the Intel > >and Nokia approaches is the best direction; taking the netlink > >communication approach from the Intel drivers, and the > >device-independence (and supplicant communication approach) > >from the Nokia drivers. > > > >Basically, WE is dead dead dead, and should no longer be used > >under any circumstances. A specific WiMAX netlink > >communications system should be used, like Intel has done. > >But there are still concerns upstream with the > >device-specificity of the kernel/userspace API as Intel has written it. > > > >I guess you guys just rewrote the Intel drivers, or wrote new > >drivers from scratch for the 2400 hardware? > > > >Dan > > > > The Nokia driver is not a rewrite of any Intel driver, it is has been > written from scratch by Nokia, and as far as I know well before the > Intel WiMAX Linux development had really speeded up. > > Although I share your view on WE, and I think a netlink message based > interface would be elegant, I'm not sure how the community will view a > driver interface without IOCTL based control. We're moving to netlink-based stuff upstream anyway, with a new tool 'iw' based on that netlink based interface. The community will have to deal with it, because WE is completely frozen and dead. There are features that many people in the community want (that used to be implemented with iwpriv) that will only be implemented with the netlink interface, and kernel support for WE will be moved over to WE-compat code that simply translates the WE calls into the netlink handlers anyway. Nobody likes WE, and nobody wants to maintain it going forward. We shouldn't be adding _new_ ioctls based on the WE design; anything that does certainly won't go upstream. Dan > I agree with you. The best solution would be a fusion. A netlink message > based interface with the abstract WiMAX operations (with interface > abstraction at the level used in the Nokia driver) would be the way to > start defining a uniform WiMAX driver interface for Linux. > > > -Juuso > > >> methods defined in the interface have been proven to work on a real > >> product, and could serve as good reference defining a device > >> independent WiMAX driver interface for Linux. > >> > >> It is my personal feeling that the Nokia approach is closer > >to what is > >> intended by the driver model in operating systems, such as Linux.
