Message ID | 1404980258-30853-2-git-send-email-teg@jklm.no |
---|---|
State | Changes Requested, archived |
Delegated to: | David Miller |
Headers | show |
Le 10/07/2014 10:17, Tom Gundersen a écrit : > Based on a patch by David Herrmann. > > The name_assign_type attribute gives hints where the interface name of a > given net-device comes from. These values are currently defined: > NET_NAME_ENUM: > The ifname is provided by the kernel with an enumerated > suffix, typically based on order of discovery. Names may > be reused and unpredictable. > NET_NAME_PREDICTABLE: > The ifname has been assigned by the kernel in a predictable way > that is guaranteed to avoid reuse and always be the same for a > given device. Examples include statically created devices like > the loopback device and names deduced from hardware properties > (including being given explicitly by the firmware). Names > depending on the order of discovery, or in any other way on the > existence of other devices, must not be marked as PREDICTABLE. > NET_NAME_USER: > The ifname was provided by user-space during net-device setup. > NET_NAME_RENAMED: > The net-device has been renamed from userspace. Once this type is set, > it cannot change again. > NET_NAME_UNKNOWN: > This is an internal placeholder to indicate that we yet haven't yet > categorized the name. It will not be exposed to userspace, rather > -EINVAL is returned. > > The aim of these patches is to improve user-space renaming of interfaces. As > a general rule, userspace must rename interfaces to guarantee that names stay > the same every time a given piece of hardware appears (at boot, or when > attaching it). However, there are several situations where userspace should > not perform the renaming, and that depends on both the policy of the local > admin, but crucially also on the nature of the current interface name. > > If an interface was created in repsonse to a userspace request, and userspace > already provided a name, we most probably want to leave that name alone. The > main instance of this is wifi-P2P devices created over nl80211, which currently > have a long-standing bug where they are getting renamed by udev. We label such > names NET_NAME_USER. > > If an interface, unbeknown to us, has already been renamed from userspace, we > most probably want to leave also that alone. This will typically happen when > third-party plugins (for instance to udev, but the interface is generic so could > be from anywhere) renames the interface without informing udev about it. A > typical situation is when you switch root from an installer or an initrd to the > real system and the new instance of udev does not know what happened before > the switch. These types of problems have caused repeated issues in the past. To > solve this, once an interface has been renamed, its name is labelled > NET_NAME_RENAMED. > > In many cases, the kernel is actually able to name interfaces in such a > way that there is no need for userspace to rename them. This is the case when > the enumeration order of devices, or in fact any other (non-parent) device on > the system, can not influence the name of the interface. Examples include > statically created devices, or any naming schemes based on hardware properties > of the interface. In this case the admin may prefer to use the kernel-provided > names, and to make that possible we label such names NET_NAME_PREDICTABLE. > We want the kernel to have tho possibilty of performing predictable interface > naming itself (and exposing to userspace that it has), as the information > necessary for a proper naming scheme for a certain class of devices may not > be exposed to userspace. > > The case where renaming is almost certainly desired, is when the kernel has > given the interface a name using global device enumeration based on order of > discovery (ethX, wlanY, etc). These naming schemes are labelled NET_NAME_ENUM. > > Lastly, a fallback is left as NET_NAME_UNKNOWN, to indicate that a driver has > not yet been ported. This is mostly useful as a transitionary measure, allowing > us to label the various naming schemes bit by bit. > > Signed-off-by: Tom Gundersen <teg@jklm.no> > Reviewed-by: David Herrmann <dh.herrmann@gmail.com> > Reviewed-by: Kay Sievers <kay@vrfy.org> > --- > Documentation/ABI/testing/sysfs-class-net | 11 +++++++++++ > include/linux/netdevice.h | 2 ++ > include/uapi/linux/netdevice.h | 6 ++++++ > net/core/net-sysfs.c | 20 ++++++++++++++++++++ > 4 files changed, 39 insertions(+) > > diff --git a/Documentation/ABI/testing/sysfs-class-net b/Documentation/ABI/testing/sysfs-class-net > index 416c5d5..d34280a 100644 > --- a/Documentation/ABI/testing/sysfs-class-net > +++ b/Documentation/ABI/testing/sysfs-class-net > @@ -1,3 +1,14 @@ > +What: /sys/class/net/<iface>/name_assign_type > +Date: July 2014 > +KernelVersion: 3.2 > +Contact: netdev@vger.kernel.org > +Description: > + Indicates the name assignment type. Possible values are: > + 1: enumerated by the kernel, possibly in an unpredictable way > + 2: predictably named by the kernel > + 3: named by userspace > + 4: renamed > + > What: /sys/class/net/<iface>/addr_assign_type > Date: July 2010 > KernelVersion: 3.2 > diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h > index 66f9a04..551e187 100644 > --- a/include/linux/netdevice.h > +++ b/include/linux/netdevice.h > @@ -1379,6 +1379,8 @@ struct net_device { > struct kset *queues_kset; > #endif > > + unsigned char name_assign_type; > + > bool uc_promisc; > unsigned int promiscuity; > unsigned int allmulti; > diff --git a/include/uapi/linux/netdevice.h b/include/uapi/linux/netdevice.h > index fdfbd1c..82e630a 100644 > --- a/include/uapi/linux/netdevice.h > +++ b/include/uapi/linux/netdevice.h > @@ -37,6 +37,12 @@ > #define INIT_NETDEV_GROUP 0 > > > +/* interface name assignment types (sysfs name_assign_type attribute) */ > +#define NET_NAME_UNKNOWN 0 /* unknown origin (not exposed to userspace) */ > +#define NET_NAME_ENUM 1 /* enumerated by kernel */ > +#define NET_NAME_PREDICTABLE 2 /* predictably named by the kernel */ Nitpicking: there is spaces instead tabs between '2' and the comment. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 10-07-14 10:17, Tom Gundersen wrote: > Based on a patch by David Herrmann. > > The name_assign_type attribute gives hints where the interface name of a > given net-device comes from. These values are currently defined: > NET_NAME_ENUM: > The ifname is provided by the kernel with an enumerated > suffix, typically based on order of discovery. Names may > be reused and unpredictable. > NET_NAME_PREDICTABLE: > The ifname has been assigned by the kernel in a predictable way > that is guaranteed to avoid reuse and always be the same for a > given device. Examples include statically created devices like > the loopback device and names deduced from hardware properties > (including being given explicitly by the firmware). Names > depending on the order of discovery, or in any other way on the > existence of other devices, must not be marked as PREDICTABLE. > NET_NAME_USER: > The ifname was provided by user-space during net-device setup. > NET_NAME_RENAMED: > The net-device has been renamed from userspace. Once this type is set, > it cannot change again. > NET_NAME_UNKNOWN: > This is an internal placeholder to indicate that we yet haven't yet > categorized the name. It will not be exposed to userspace, rather > -EINVAL is returned. > > The aim of these patches is to improve user-space renaming of interfaces. As > a general rule, userspace must rename interfaces to guarantee that names stay > the same every time a given piece of hardware appears (at boot, or when > attaching it). However, there are several situations where userspace should > not perform the renaming, and that depends on both the policy of the local > admin, but crucially also on the nature of the current interface name. > > If an interface was created in repsonse to a userspace request, and userspace > already provided a name, we most probably want to leave that name alone. The > main instance of this is wifi-P2P devices created over nl80211, which currently > have a long-standing bug where they are getting renamed by udev. We label such > names NET_NAME_USER. > > If an interface, unbeknown to us, has already been renamed from userspace, we > most probably want to leave also that alone. This will typically happen when > third-party plugins (for instance to udev, but the interface is generic so could > be from anywhere) renames the interface without informing udev about it. A > typical situation is when you switch root from an installer or an initrd to the > real system and the new instance of udev does not know what happened before > the switch. These types of problems have caused repeated issues in the past. To > solve this, once an interface has been renamed, its name is labelled > NET_NAME_RENAMED. > > In many cases, the kernel is actually able to name interfaces in such a > way that there is no need for userspace to rename them. This is the case when > the enumeration order of devices, or in fact any other (non-parent) device on > the system, can not influence the name of the interface. Examples include > statically created devices, or any naming schemes based on hardware properties > of the interface. In this case the admin may prefer to use the kernel-provided > names, and to make that possible we label such names NET_NAME_PREDICTABLE. > We want the kernel to have tho possibilty of performing predictable interface > naming itself (and exposing to userspace that it has), as the information > necessary for a proper naming scheme for a certain class of devices may not > be exposed to userspace. > > The case where renaming is almost certainly desired, is when the kernel has > given the interface a name using global device enumeration based on order of > discovery (ethX, wlanY, etc). These naming schemes are labelled NET_NAME_ENUM. > > Lastly, a fallback is left as NET_NAME_UNKNOWN, to indicate that a driver has > not yet been ported. This is mostly useful as a transitionary measure, allowing > us to label the various naming schemes bit by bit. > > Signed-off-by: Tom Gundersen <teg@jklm.no> > Reviewed-by: David Herrmann <dh.herrmann@gmail.com> > Reviewed-by: Kay Sievers <kay@vrfy.org> > --- > Documentation/ABI/testing/sysfs-class-net | 11 +++++++++++ > include/linux/netdevice.h | 2 ++ > include/uapi/linux/netdevice.h | 6 ++++++ > net/core/net-sysfs.c | 20 ++++++++++++++++++++ > 4 files changed, 39 insertions(+) > > diff --git a/Documentation/ABI/testing/sysfs-class-net b/Documentation/ABI/testing/sysfs-class-net > index 416c5d5..d34280a 100644 > --- a/Documentation/ABI/testing/sysfs-class-net > +++ b/Documentation/ABI/testing/sysfs-class-net > @@ -1,3 +1,14 @@ > +What: /sys/class/net/<iface>/name_assign_type > +Date: July 2014 > +KernelVersion: 3.2 Is this a copy&paste error. I guess it will be 3.17+, right? > +Contact: netdev@vger.kernel.org > +Description: > + Indicates the name assignment type. Possible values are: > + 1: enumerated by the kernel, possibly in an unpredictable way > + 2: predictably named by the kernel > + 3: named by userspace > + 4: renamed > + > What: /sys/class/net/<iface>/addr_assign_type > Date: July 2010 > KernelVersion: 3.2 > diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h > index 66f9a04..551e187 100644 > --- a/include/linux/netdevice.h > +++ b/include/linux/netdevice.h > @@ -1379,6 +1379,8 @@ struct net_device { > struct kset *queues_kset; > #endif > > + unsigned char name_assign_type; > + > bool uc_promisc; > unsigned int promiscuity; > unsigned int allmulti; > diff --git a/include/uapi/linux/netdevice.h b/include/uapi/linux/netdevice.h > index fdfbd1c..82e630a 100644 > --- a/include/uapi/linux/netdevice.h > +++ b/include/uapi/linux/netdevice.h > @@ -37,6 +37,12 @@ > #define INIT_NETDEV_GROUP 0 > > > +/* interface name assignment types (sysfs name_assign_type attribute) */ > +#define NET_NAME_UNKNOWN 0 /* unknown origin (not exposed to userspace) */ > +#define NET_NAME_ENUM 1 /* enumerated by kernel */ > +#define NET_NAME_PREDICTABLE 2 /* predictably named by the kernel */ > +#define NET_NAME_USER 3 /* provided by user-space */ > +#define NET_NAME_RENAMED 4 /* renamed by user-space */ > > /* Media selection options. */ > enum { > diff --git a/net/core/net-sysfs.c b/net/core/net-sysfs.c > index 1cac29e..7752f2a 100644 > --- a/net/core/net-sysfs.c > +++ b/net/core/net-sysfs.c > @@ -112,6 +112,25 @@ NETDEVICE_SHOW_RO(ifindex, fmt_dec); > NETDEVICE_SHOW_RO(type, fmt_dec); > NETDEVICE_SHOW_RO(link_mode, fmt_dec); > > +static ssize_t format_name_assign_type(const struct net_device *net, char *buf) > +{ > + return sprintf(buf, fmt_dec, net->name_assign_type); > +} > + > +static ssize_t name_assign_type_show(struct device *dev, > + struct device_attribute *attr, > + char *buf) > +{ > + struct net_device *net = to_net_dev(dev); > + ssize_t ret = -EINVAL; > + > + if (net->name_assign_type != NET_NAME_UNKNOWN) > + ret = netdev_show(dev, attr, buf, format_name_assign_type); > + > + return ret; > +} > +static DEVICE_ATTR_RO(name_assign_type); > + > /* use same locking rules as GIFHWADDR ioctl's */ > static ssize_t address_show(struct device *dev, struct device_attribute *attr, > char *buf) > @@ -387,6 +406,7 @@ static struct attribute *net_class_attrs[] = { > &dev_attr_dev_port.attr, > &dev_attr_iflink.attr, > &dev_attr_ifindex.attr, > + &dev_attr_name_assign_type.attr, > &dev_attr_addr_assign_type.attr, > &dev_attr_addr_len.attr, > &dev_attr_link_mode.attr, > -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Jul 10, 2014 at 5:53 PM, Nicolas Dichtel <nicolas.dichtel@6wind.com> wrote: > Le 10/07/2014 10:17, Tom Gundersen a écrit : > >> Based on a patch by David Herrmann. >> >> The name_assign_type attribute gives hints where the interface name of a >> given net-device comes from. These values are currently defined: >> NET_NAME_ENUM: >> The ifname is provided by the kernel with an enumerated >> suffix, typically based on order of discovery. Names may >> be reused and unpredictable. >> NET_NAME_PREDICTABLE: >> The ifname has been assigned by the kernel in a predictable way >> that is guaranteed to avoid reuse and always be the same for a >> given device. Examples include statically created devices like >> the loopback device and names deduced from hardware properties >> (including being given explicitly by the firmware). Names >> depending on the order of discovery, or in any other way on the >> existence of other devices, must not be marked as PREDICTABLE. >> NET_NAME_USER: >> The ifname was provided by user-space during net-device setup. >> NET_NAME_RENAMED: >> The net-device has been renamed from userspace. Once this type is >> set, >> it cannot change again. >> NET_NAME_UNKNOWN: >> This is an internal placeholder to indicate that we yet haven't yet >> categorized the name. It will not be exposed to userspace, rather >> -EINVAL is returned. >> >> The aim of these patches is to improve user-space renaming of interfaces. >> As >> a general rule, userspace must rename interfaces to guarantee that names >> stay >> the same every time a given piece of hardware appears (at boot, or when >> attaching it). However, there are several situations where userspace >> should >> not perform the renaming, and that depends on both the policy of the local >> admin, but crucially also on the nature of the current interface name. >> >> If an interface was created in repsonse to a userspace request, and >> userspace >> already provided a name, we most probably want to leave that name alone. >> The >> main instance of this is wifi-P2P devices created over nl80211, which >> currently >> have a long-standing bug where they are getting renamed by udev. We label >> such >> names NET_NAME_USER. >> >> If an interface, unbeknown to us, has already been renamed from userspace, >> we >> most probably want to leave also that alone. This will typically happen >> when >> third-party plugins (for instance to udev, but the interface is generic so >> could >> be from anywhere) renames the interface without informing udev about it. A >> typical situation is when you switch root from an installer or an initrd >> to the >> real system and the new instance of udev does not know what happened >> before >> the switch. These types of problems have caused repeated issues in the >> past. To >> solve this, once an interface has been renamed, its name is labelled >> NET_NAME_RENAMED. >> >> In many cases, the kernel is actually able to name interfaces in such a >> way that there is no need for userspace to rename them. This is the case >> when >> the enumeration order of devices, or in fact any other (non-parent) device >> on >> the system, can not influence the name of the interface. Examples include >> statically created devices, or any naming schemes based on hardware >> properties >> of the interface. In this case the admin may prefer to use the >> kernel-provided >> names, and to make that possible we label such names NET_NAME_PREDICTABLE. >> We want the kernel to have tho possibilty of performing predictable >> interface >> naming itself (and exposing to userspace that it has), as the information >> necessary for a proper naming scheme for a certain class of devices may >> not >> be exposed to userspace. >> >> The case where renaming is almost certainly desired, is when the kernel >> has >> given the interface a name using global device enumeration based on order >> of >> discovery (ethX, wlanY, etc). These naming schemes are labelled >> NET_NAME_ENUM. >> >> Lastly, a fallback is left as NET_NAME_UNKNOWN, to indicate that a driver >> has >> not yet been ported. This is mostly useful as a transitionary measure, >> allowing >> us to label the various naming schemes bit by bit. >> >> Signed-off-by: Tom Gundersen <teg@jklm.no> >> Reviewed-by: David Herrmann <dh.herrmann@gmail.com> >> Reviewed-by: Kay Sievers <kay@vrfy.org> >> --- >> Documentation/ABI/testing/sysfs-class-net | 11 +++++++++++ >> include/linux/netdevice.h | 2 ++ >> include/uapi/linux/netdevice.h | 6 ++++++ >> net/core/net-sysfs.c | 20 ++++++++++++++++++++ >> 4 files changed, 39 insertions(+) >> >> diff --git a/Documentation/ABI/testing/sysfs-class-net >> b/Documentation/ABI/testing/sysfs-class-net >> index 416c5d5..d34280a 100644 >> --- a/Documentation/ABI/testing/sysfs-class-net >> +++ b/Documentation/ABI/testing/sysfs-class-net >> @@ -1,3 +1,14 @@ >> +What: /sys/class/net/<iface>/name_assign_type >> +Date: July 2014 >> +KernelVersion: 3.2 >> +Contact: netdev@vger.kernel.org >> +Description: >> + Indicates the name assignment type. Possible values are: >> + 1: enumerated by the kernel, possibly in an unpredictable >> way >> + 2: predictably named by the kernel >> + 3: named by userspace >> + 4: renamed >> + >> What: /sys/class/net/<iface>/addr_assign_type >> Date: July 2010 >> KernelVersion: 3.2 >> diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h >> index 66f9a04..551e187 100644 >> --- a/include/linux/netdevice.h >> +++ b/include/linux/netdevice.h >> @@ -1379,6 +1379,8 @@ struct net_device { >> struct kset *queues_kset; >> #endif >> >> + unsigned char name_assign_type; >> + >> bool uc_promisc; >> unsigned int promiscuity; >> unsigned int allmulti; >> diff --git a/include/uapi/linux/netdevice.h >> b/include/uapi/linux/netdevice.h >> index fdfbd1c..82e630a 100644 >> --- a/include/uapi/linux/netdevice.h >> +++ b/include/uapi/linux/netdevice.h >> @@ -37,6 +37,12 @@ >> #define INIT_NETDEV_GROUP 0 >> >> >> +/* interface name assignment types (sysfs name_assign_type attribute) */ >> +#define NET_NAME_UNKNOWN 0 /* unknown origin (not exposed to >> userspace) */ >> +#define NET_NAME_ENUM 1 /* enumerated by kernel */ >> +#define NET_NAME_PREDICTABLE 2 /* predictably named by the kernel >> */ > > Nitpicking: there is spaces instead tabs between '2' and the comment. Indeed. Fixed. Thanks. Tom -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Jul 10, 2014 at 9:58 PM, Arend van Spriel <arend@broadcom.com> wrote: > On 10-07-14 10:17, Tom Gundersen wrote: >> Based on a patch by David Herrmann. >> >> The name_assign_type attribute gives hints where the interface name of a >> given net-device comes from. These values are currently defined: >> NET_NAME_ENUM: >> The ifname is provided by the kernel with an enumerated >> suffix, typically based on order of discovery. Names may >> be reused and unpredictable. >> NET_NAME_PREDICTABLE: >> The ifname has been assigned by the kernel in a predictable way >> that is guaranteed to avoid reuse and always be the same for a >> given device. Examples include statically created devices like >> the loopback device and names deduced from hardware properties >> (including being given explicitly by the firmware). Names >> depending on the order of discovery, or in any other way on the >> existence of other devices, must not be marked as PREDICTABLE. >> NET_NAME_USER: >> The ifname was provided by user-space during net-device setup. >> NET_NAME_RENAMED: >> The net-device has been renamed from userspace. Once this type is set, >> it cannot change again. >> NET_NAME_UNKNOWN: >> This is an internal placeholder to indicate that we yet haven't yet >> categorized the name. It will not be exposed to userspace, rather >> -EINVAL is returned. >> >> The aim of these patches is to improve user-space renaming of interfaces. As >> a general rule, userspace must rename interfaces to guarantee that names stay >> the same every time a given piece of hardware appears (at boot, or when >> attaching it). However, there are several situations where userspace should >> not perform the renaming, and that depends on both the policy of the local >> admin, but crucially also on the nature of the current interface name. >> >> If an interface was created in repsonse to a userspace request, and userspace >> already provided a name, we most probably want to leave that name alone. The >> main instance of this is wifi-P2P devices created over nl80211, which currently >> have a long-standing bug where they are getting renamed by udev. We label such >> names NET_NAME_USER. >> >> If an interface, unbeknown to us, has already been renamed from userspace, we >> most probably want to leave also that alone. This will typically happen when >> third-party plugins (for instance to udev, but the interface is generic so could >> be from anywhere) renames the interface without informing udev about it. A >> typical situation is when you switch root from an installer or an initrd to the >> real system and the new instance of udev does not know what happened before >> the switch. These types of problems have caused repeated issues in the past. To >> solve this, once an interface has been renamed, its name is labelled >> NET_NAME_RENAMED. >> >> In many cases, the kernel is actually able to name interfaces in such a >> way that there is no need for userspace to rename them. This is the case when >> the enumeration order of devices, or in fact any other (non-parent) device on >> the system, can not influence the name of the interface. Examples include >> statically created devices, or any naming schemes based on hardware properties >> of the interface. In this case the admin may prefer to use the kernel-provided >> names, and to make that possible we label such names NET_NAME_PREDICTABLE. >> We want the kernel to have tho possibilty of performing predictable interface >> naming itself (and exposing to userspace that it has), as the information >> necessary for a proper naming scheme for a certain class of devices may not >> be exposed to userspace. >> >> The case where renaming is almost certainly desired, is when the kernel has >> given the interface a name using global device enumeration based on order of >> discovery (ethX, wlanY, etc). These naming schemes are labelled NET_NAME_ENUM. >> >> Lastly, a fallback is left as NET_NAME_UNKNOWN, to indicate that a driver has >> not yet been ported. This is mostly useful as a transitionary measure, allowing >> us to label the various naming schemes bit by bit. >> >> Signed-off-by: Tom Gundersen <teg@jklm.no> >> Reviewed-by: David Herrmann <dh.herrmann@gmail.com> >> Reviewed-by: Kay Sievers <kay@vrfy.org> >> --- >> Documentation/ABI/testing/sysfs-class-net | 11 +++++++++++ >> include/linux/netdevice.h | 2 ++ >> include/uapi/linux/netdevice.h | 6 ++++++ >> net/core/net-sysfs.c | 20 ++++++++++++++++++++ >> 4 files changed, 39 insertions(+) >> >> diff --git a/Documentation/ABI/testing/sysfs-class-net b/Documentation/ABI/testing/sysfs-class-net >> index 416c5d5..d34280a 100644 >> --- a/Documentation/ABI/testing/sysfs-class-net >> +++ b/Documentation/ABI/testing/sysfs-class-net >> @@ -1,3 +1,14 @@ >> +What: /sys/class/net/<iface>/name_assign_type >> +Date: July 2014 >> +KernelVersion: 3.2 > > Is this a copy&paste error. I guess it will be 3.17+, right? Yeah. Fixed that one too. Thanks. Tom >> +Contact: netdev@vger.kernel.org >> +Description: >> + Indicates the name assignment type. Possible values are: >> + 1: enumerated by the kernel, possibly in an unpredictable way >> + 2: predictably named by the kernel >> + 3: named by userspace >> + 4: renamed >> + >> What: /sys/class/net/<iface>/addr_assign_type >> Date: July 2010 >> KernelVersion: 3.2 >> diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h >> index 66f9a04..551e187 100644 >> --- a/include/linux/netdevice.h >> +++ b/include/linux/netdevice.h >> @@ -1379,6 +1379,8 @@ struct net_device { >> struct kset *queues_kset; >> #endif >> >> + unsigned char name_assign_type; >> + >> bool uc_promisc; >> unsigned int promiscuity; >> unsigned int allmulti; >> diff --git a/include/uapi/linux/netdevice.h b/include/uapi/linux/netdevice.h >> index fdfbd1c..82e630a 100644 >> --- a/include/uapi/linux/netdevice.h >> +++ b/include/uapi/linux/netdevice.h >> @@ -37,6 +37,12 @@ >> #define INIT_NETDEV_GROUP 0 >> >> >> +/* interface name assignment types (sysfs name_assign_type attribute) */ >> +#define NET_NAME_UNKNOWN 0 /* unknown origin (not exposed to userspace) */ >> +#define NET_NAME_ENUM 1 /* enumerated by kernel */ >> +#define NET_NAME_PREDICTABLE 2 /* predictably named by the kernel */ >> +#define NET_NAME_USER 3 /* provided by user-space */ >> +#define NET_NAME_RENAMED 4 /* renamed by user-space */ >> >> /* Media selection options. */ >> enum { >> diff --git a/net/core/net-sysfs.c b/net/core/net-sysfs.c >> index 1cac29e..7752f2a 100644 >> --- a/net/core/net-sysfs.c >> +++ b/net/core/net-sysfs.c >> @@ -112,6 +112,25 @@ NETDEVICE_SHOW_RO(ifindex, fmt_dec); >> NETDEVICE_SHOW_RO(type, fmt_dec); >> NETDEVICE_SHOW_RO(link_mode, fmt_dec); >> >> +static ssize_t format_name_assign_type(const struct net_device *net, char *buf) >> +{ >> + return sprintf(buf, fmt_dec, net->name_assign_type); >> +} >> + >> +static ssize_t name_assign_type_show(struct device *dev, >> + struct device_attribute *attr, >> + char *buf) >> +{ >> + struct net_device *net = to_net_dev(dev); >> + ssize_t ret = -EINVAL; >> + >> + if (net->name_assign_type != NET_NAME_UNKNOWN) >> + ret = netdev_show(dev, attr, buf, format_name_assign_type); >> + >> + return ret; >> +} >> +static DEVICE_ATTR_RO(name_assign_type); >> + >> /* use same locking rules as GIFHWADDR ioctl's */ >> static ssize_t address_show(struct device *dev, struct device_attribute *attr, >> char *buf) >> @@ -387,6 +406,7 @@ static struct attribute *net_class_attrs[] = { >> &dev_attr_dev_port.attr, >> &dev_attr_iflink.attr, >> &dev_attr_ifindex.attr, >> + &dev_attr_name_assign_type.attr, >> &dev_attr_addr_assign_type.attr, >> &dev_attr_addr_len.attr, >> &dev_attr_link_mode.attr, >> > -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/Documentation/ABI/testing/sysfs-class-net b/Documentation/ABI/testing/sysfs-class-net index 416c5d5..d34280a 100644 --- a/Documentation/ABI/testing/sysfs-class-net +++ b/Documentation/ABI/testing/sysfs-class-net @@ -1,3 +1,14 @@ +What: /sys/class/net/<iface>/name_assign_type +Date: July 2014 +KernelVersion: 3.2 +Contact: netdev@vger.kernel.org +Description: + Indicates the name assignment type. Possible values are: + 1: enumerated by the kernel, possibly in an unpredictable way + 2: predictably named by the kernel + 3: named by userspace + 4: renamed + What: /sys/class/net/<iface>/addr_assign_type Date: July 2010 KernelVersion: 3.2 diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h index 66f9a04..551e187 100644 --- a/include/linux/netdevice.h +++ b/include/linux/netdevice.h @@ -1379,6 +1379,8 @@ struct net_device { struct kset *queues_kset; #endif + unsigned char name_assign_type; + bool uc_promisc; unsigned int promiscuity; unsigned int allmulti; diff --git a/include/uapi/linux/netdevice.h b/include/uapi/linux/netdevice.h index fdfbd1c..82e630a 100644 --- a/include/uapi/linux/netdevice.h +++ b/include/uapi/linux/netdevice.h @@ -37,6 +37,12 @@ #define INIT_NETDEV_GROUP 0 +/* interface name assignment types (sysfs name_assign_type attribute) */ +#define NET_NAME_UNKNOWN 0 /* unknown origin (not exposed to userspace) */ +#define NET_NAME_ENUM 1 /* enumerated by kernel */ +#define NET_NAME_PREDICTABLE 2 /* predictably named by the kernel */ +#define NET_NAME_USER 3 /* provided by user-space */ +#define NET_NAME_RENAMED 4 /* renamed by user-space */ /* Media selection options. */ enum { diff --git a/net/core/net-sysfs.c b/net/core/net-sysfs.c index 1cac29e..7752f2a 100644 --- a/net/core/net-sysfs.c +++ b/net/core/net-sysfs.c @@ -112,6 +112,25 @@ NETDEVICE_SHOW_RO(ifindex, fmt_dec); NETDEVICE_SHOW_RO(type, fmt_dec); NETDEVICE_SHOW_RO(link_mode, fmt_dec); +static ssize_t format_name_assign_type(const struct net_device *net, char *buf) +{ + return sprintf(buf, fmt_dec, net->name_assign_type); +} + +static ssize_t name_assign_type_show(struct device *dev, + struct device_attribute *attr, + char *buf) +{ + struct net_device *net = to_net_dev(dev); + ssize_t ret = -EINVAL; + + if (net->name_assign_type != NET_NAME_UNKNOWN) + ret = netdev_show(dev, attr, buf, format_name_assign_type); + + return ret; +} +static DEVICE_ATTR_RO(name_assign_type); + /* use same locking rules as GIFHWADDR ioctl's */ static ssize_t address_show(struct device *dev, struct device_attribute *attr, char *buf) @@ -387,6 +406,7 @@ static struct attribute *net_class_attrs[] = { &dev_attr_dev_port.attr, &dev_attr_iflink.attr, &dev_attr_ifindex.attr, + &dev_attr_name_assign_type.attr, &dev_attr_addr_assign_type.attr, &dev_attr_addr_len.attr, &dev_attr_link_mode.attr,