Re: reviving OLPC & NetworkManager-0.7 work

[Dan Williams <dcbw redhat com>]

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