>From: ext Inaky Perez-Gonzalez [mailto:inaky@xxxxxxxxxxxxxxx] >Sent: 2. joulukuuta 2008 21:55 > >On Monday 01 December 2008, juuso.oikarinen@xxxxxxxxx wrote: >> ... >> >> 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/ > >Thanks for posting this! > >Is there a roadmap to the driver? The sources publicized are from the currently selling device. They are rather old, there you are right. True ND&S is still does not exist in the "real world" but NSP discovery methods exist in the Nokia interface already. While I cannot discuss roadmaps or schedules directly, I think the one think requiring attention in the future are issues related to QoS and service flows. >I have a few questions -- I haven't been able to go over the >whole driver, so please bear with me: > >- where do you guys implement the supplicant? if you put >everything below the kernel, it will be needed there? If you look at the source, you will see that EAP messages are transmitted out into user space encapsulated in ethernet frames. The supplicant is running in user space. This approach was adopted from pre-existing WLAN implementations. >- how do you manage OMA-DM interaction with the networks to >get the provisioning information from the networks? This >cannot be put in kernel space and still is needed. The OMA-DM implementation also exists in user-space. "Everything" in kernel-space is not entirely true. Everything device specific in kernel-space is true. ND&S and provisioning is not device specific - so it is implemented in the "connection manager" in user space. The driver merely provides the connection manager the tools to perform ND&S, such as NAP scanning or NSP discovery. >- Why do you need an OSAL? The OSAL provides a intentionally limited, unified set of operations to write device driver code. The OSAL can be nearly directly ported to any other platform. This enables effortless porting, or let's say "cross-using" of the device specific code in any other platform with ease. >> 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 >> 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. In the Nokia architechture, the components that are running in user space are basically device-independent. The only device dependent code exists in the device driver (in kernel space), within the boundaries of the OSAL. While we do think the OSAL is ingenious, we are not trying to standardize that. We do drive a standardized kernel-user-space interface for WiMAX - one that is device independent as it should be. The methods currently supported by the Nokia driver are in pc2400m_if_we.[ch]. We think that the abstraction level in the Nokia driver interface could serve as reference, because it's already proven. The ND&S logic is in user space. It relies on the driver interface, which is device independent. >Thanks, > >-- >Inaky >
