On Mon, 2005-14-11 at 16:48 +0100, Stefan Rompf wrote: > Am Montag 14 November 2005 14:57 schrieb jamal: > > > My suggestion is at this point to ignore any L3 issues and have people > > post their patches. RFC 2863 states MUST be taken into consideration. > > Proper naming must be taken into account. > > here we go. I've removed OPER_DORMANTL3* as requested and changed it to one > dormant state. I've changed VLAN to support OPER_LOWERLAYERDOWN to show how > the code can work with stacked interfaces. Locking fixes. > > Main reasons why I chose this approach: > > -kernel operstate is consistent when calling into linkwatch_fire_event() > -userspace override is independant, no different codepaths on wireless > association with or without WPA enabled > > Todo: > > -userspace interface, netlink message/ioctl to read netif_get_operstate(), > netif_get_operstate() for userspace supplicant, operstate_useroverride > -userspace interface, netlink message/ioctl to set operstate_useroverride, > possibly with automatic reset to OPERU_IGNORE when application closes fd.
General comments; i am only gonna provide the negatives all else is positive: 1) I dont think operstare_useroverride is needed. a) We need new flags which get reflected to user space; i.e new IFF_XXX flags. DOWN/UP are already being reflected by IFF_RUNNING. We need LOWERLAYERDOWN and DORMANT; i am not sure if we need to represent to TESTING, UNKNOWN and NOT_PRESENT. I wonder if IFF_DEBUG can be used for TESTING state. b) I think we need the dev->operstate_kernel to behave in a similar manner as dev->state. Despite that we already have rtnl_lock at that point it will be consistent to use the set/clear_bit etc. Look at the transfer on IFF_UP to/from dev->state in the case of open/close (net/core/dev.c::dev_open/close); or even look at flag changes. 2) the netdev_operstate: why do you have the enumeration setting the way you do? The checks of sort >/>=/</<= all over the code will end up causing problems by reducing extensibility should we in the future decide to add more states. I cant foresee any new states in the near future, but it is cleaner IMO. cheers, jamal - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
