On Mon, 2009-06-08 at 17:19 +0100, Daniel Drake wrote: > Hi, > > I'm working to get the OLPC mesh interface working with new > NetworkManager releases and to get suitable code upstream. I would also > like to get this backported into Fedora 11 for OLPC's XO-1.5 software > build. > > What is the suggested approach I should take here? > > Should I work with git master and then backport to 0.7 after? (how > usable is that? how much trouble can I expect trying to get it > operational on F11 for development purposes?) > > I'm aware of Sjoerd Simon's previous work, and have looked over the > discussion that resulted on the last set of submitted patches. > > So far I have taken his work, and reworked the patches based on the > earlier feedback and recent NM changes, against 0.7 HEAD: > git://dev.laptop.org/users/dsd/NetworkManager branch "olpc" > http://dev.laptop.org/git/users/dsd/NetworkManager/log/?h=olpc > > I've also done some basic tests on an XO, it is working. > > Dan, I'd also appreciate it if you could take a very quick look at the > style of the OLPC mesh device implementation: > http://dev.laptop.org/git/users/dsd/NetworkManager/commit/?h=olpc&id=4b5095bdb843667eba215d15232cdfd5c27f53be > There are rough edges and FIXMEs to be handled, but it would be nice to > know whether we are on the right lines for an upstream-acceptable > implementation or not.
I hesitate to call it NMSettingMesh, because the OLPC-style mesh is pretty unique and doesn't map exactly to 802.11s. Maybe we can make the setting work for both, but I'd like some more input from Jouni and Johannes before committing to adding that setting to the API. Need to ask them whether the values in that structure make any sense in generic 802.11s deployments. I'm pretty sure dhcp-anycast-address *doesn't*, but if it's just one value that's probably OK. If it turns out we just want to be doing an OLPC-specific mesh setting implementation, then we don't need any of the checking against A-band addresses in nm-setting-mesh.c::verify(). You can ignore anything to do with wpa_supplicant (like in real_can_activate()) since I'm pretty sure the supplicant will never got olpc mesh support, or at least it won't in the near future. So since NM is manually controlling the OLPC mesh interface here, we can just get rid of that left-over from nm-device-wifi.c. If you could rename nm_device_olpc_prepare() to something else like get_socket() too; prepare doesn't really sound right to me. Indentation at the bottom of real_act_stage2_config() wants fixing. real_act_stage4_get_ip4_config() doesn't need to exist if all its doing is calling up to the superclass. NM_DEVICE_OLPC_MESH_MODE is only ever going to be mesh, so does it need to be exist? companion_notify_cb() is only used for 'scanning', so attach to the "notify::scanning" signal and you don't need to check the property name in companion_notify_cb() explicitly. Indentation in state_changed_cb() wants fixing. There's a couple of instances of "NM_DEVICE_WIFI(other)", there should be a space between the I and the (. We can remove NMDeviceOlpcMeshPrivate from struct _NMDeviceOlpcMesh; it's not needed there and gets handled automatically in class_init() with g_type_class_add_private(). Indentation in struct _NMDeviceOlpcMeshClass wants fixing. And for master, you're going to have to figure out how to identify this device without using HAL, since I'm stripping out HAL support right now and converting over to using udev directly. I don't know offhand whether that means checking something in sysfs or not, since the usb8388 dongle panics my 2.6.29.4 kernel (hey, aren't I the maintainer of that upstream too? :). But we can't just rely on 'net.olpcmesh' to identify the device anymore in master. Shouldn't be too hard though. Care to clean up and post a new link to the v2? Thanks! Dan _______________________________________________ NetworkManager-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/networkmanager-list
