CVSROOT: /cvs/gnome
Module name: NetworkManager
Changes by: rml 06/03/09 16:39:17
Modified files:
. : Tag: NETWORKMANAGER_0_6_0_RELEASE ChangeLog
src : Tag: NETWORKMANAGER_0_6_0_RELEASE
nm-ap-security.h nm-device-802-11-wireless.c
nm-device-802-11-wireless.h
nm-device-802-3-ethernet.c nm-device.c
nm-device.h
vpn-daemons/openvpn/po: Tag: NETWORKMANAGER_0_6_0_RELEASE
.cvsignore
vpn-daemons/openvpn/po: Tag: NETWORKMANAGER_0_6_0_RELEASE
.cvsignore
vpn-daemons/pptp/po: Tag: NETWORKMANAGER_0_6_0_RELEASE
.cvsignore
vpn-daemons/pptp/po: Tag: NETWORKMANAGER_0_6_0_RELEASE
.cvsignore
vpn-daemons/vpnc: Tag: NETWORKMANAGER_0_6_0_RELEASE ChangeLog
nm-vpnc.desktop.in
vpn-daemons/vpnc/po: Tag: NETWORKMANAGER_0_6_0_RELEASE
.cvsignore
Log message:
2006-03-09 Robert Love <[EMAIL PROTECTED]>
* src/NetworkManagerAP.c, src/NetworkManagerAP.h: Have the function
nm_ap_set_timestamp() take the second and micro-second parameters as
direct arguments, which avoids both a dynamic memory allocation and a
structure-to-structure copy! Add a new interface, the aptly named
nm_ap_set_timestamp_via_timestamp(), to set the timestamp from an
existing GTimeVal, as nm_ap_set_timestamp() once did, for use with
the return from nm_ap_get_timestamp(). New users should use the new
nm_ap_set_timestamp(), not nm_ap_set_timestamp_via_timestamp(), for
the extreme benefit to performance.
* src/NetworkManagerAPList.c, src/nm-dbus-nmi.c,
src/backends/NetworkManagerSuSE.c: Use the new functions as needed.
2006-03-04 Dan Williams <[EMAIL PROTECTED]>
Clean up activation cancellation. Should be a lot faster now. Observed
an issue with wireless devices between stage 2 and 3 of activation, where
activation would be cancelled, but the device thread wouldn't notice until
the supplicant association timed out. Reorganize activation such that
a cancellation handler gets immediately scheduled in the device's thread,
and devices have a chance to perform any custom cleanup too.
* src/nm-device.[ch]
- (activation_cancel_handler): new device-type-specific function
for cleaning up device-type-specific stuff on cancellation
- (cancel_activation): removed
- (nm_device_activation_cancel): subsume functionality of
real_cancel_activation, but instead of doing anything, punt
operation to a handler that's run in device-thread context
- (nm_device_schedule_activation_handle_cancel): fix spelling of
a warning message
- (activation_handle_cancel_helper): cancellation handler run in
device-thread context, calls device-type-specific cancelation,
then tears down the activation request
- (real_activation_cancel_handler): generic cancellation handler,
deals with cancelling any in-process DHCP request
- (nm_device_activate_stage1_device_prepare,
nm_device_activate_stage2_device_config,
nm_device_activate_stage3_ip_config_start,
nm_device_activate_stage4_ip_config_get,
nm_device_activate_stage4_ip_config_timeout,
nm_device_activate_stage5_ip_commit): don't call
nm_device_schedule_activation_handle_cancel() any more, since
cancellation will have been already scheduled for us by
nm_device_activation_cancel(). Just exit the function and
assume that the cancel handler will be called next.
* src/nm-device-802-3-ethernet.c
- (real_act_stage2_config): remove; didn't do anything anyway
* src/nm-device-802-11-wireless.c
- (supplicant_status_cb): ensure we don't do anything if the activation
got cancelled
- (real_activation_cancel_handler): implement; cancel user key request
on activation cancellation
2006-03-04 Dan Williams <[EMAIL PROTECTED]>
* src/nm-device-802-11-wireless.c
- (supplicant_send_network_config): assume that drivers that don't
support WPA pretty much suck, and can't handle NM scanning
along with wpa_supplicant.
URL :
http://cvs.gnome.org/bonsai/cvsquery.cgi?branch=&dir=NetworkManager&who=rml&date=explicit&mindate=2006-03-09%2016:38&maxdate=2006-03-09%2016:40
_______________________________________________
cvs-commits-list mailing list
cvs-commits-list@gnome.org
http://mail.gnome.org/mailman/listinfo/cvs-commits-list
