Re: [PATCH v5 0/4] Provide netdev naming-policy via sysfs
On Sat, Mar 29, 2014 at 8:37 PM, David Miller wrote: > From: Tom Gundersen > Date: Sat, 29 Mar 2014 10:46:02 +0100 > >> The issue I see with that is that there are several ways to generate >> predictable names, and the user may want to chose between them, so >> this is arguably policy that should not be in the kernel. If you don't >> think that's a problem, I'd be happy to submit a patch to move all >> this logic from udev to the kernel, just let me know how you see it. > > Unfortunately, we have already allowed this kind of thing for setting > MAC addresses so I guess I'll have to allow your changes to be applied. > > But before I ask you to resubmit, do you have full buy-in from the > udev folks for this facility? Absolutely, it is very useful to have. Today, there is no way for userland to distinguish explicitly requested and predictable names provided by tools, from unpredictable names composed by the kernel itself by adding an unpredictable enumeration number. It allows us the work around the common problems in general purpose Linux, where we have no strong dependencies, not necessarily central management, and loose coupling between components. This information will allow us to apply best-effort or common sense to the default udev device name policies, like: - leave the name alone if someone has asked explicitly for that name - leave the name alone if someone else has already renamed it after its first creation So, having that information in /sys would be very welcome from udev's point of view. Thanks, Kay -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 0/4] Provide netdev naming-policy via sysfs
From: Tom Gundersen Date: Sat, 29 Mar 2014 10:46:02 +0100 > The issue I see with that is that there are several ways to generate > predictable names, and the user may want to chose between them, so > this is arguably policy that should not be in the kernel. If you don't > think that's a problem, I'd be happy to submit a patch to move all > this logic from udev to the kernel, just let me know how you see it. Unfortunately, we have already allowed this kind of thing for setting MAC addresses so I guess I'll have to allow your changes to be applied. But before I ask you to resubmit, do you have full buy-in from the udev folks for this facility? Thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 0/4] Provide netdev naming-policy via sysfs
On Sat, Mar 29, 2014 at 2:42 AM, David Miller wrote: > From: Tom Gundersen > Date: Fri, 28 Mar 2014 23:39:57 +0100 > >> You mean coordinate with each other in userspace? If so, I still don't >> see how this can ever be anything else than fragile. It will depend on >> each userspace component actually opting in to whatever scheme we >> devise, and does so correctly. > > Isn't that essentially what dbus is? > > A way for seperate userland components to coordinate their > activities? The protocol is not the problem. The issue is that this information only exists reliably in the kernel, so we need to get it from there somehow. > I just simply don't like all of these ramdom keys getting > added all over the place to guide udev behavior wrt. some > other entity. Well, in this case udev is sort of doing a bit of the kernel's work, and it needs some information from the kernel to do it reliably. Another approach would be for the kernel to just assign predictable interface names to devices to begin with and we would never have to touch them. You have all the information so that would be relatively easy. The issue I see with that is that there are several ways to generate predictable names, and the user may want to chose between them, so this is arguably policy that should not be in the kernel. If you don't think that's a problem, I'd be happy to submit a patch to move all this logic from udev to the kernel, just let me know how you see it. Cheers, Tom -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 0/4] Provide netdev naming-policy via sysfs
On Sat, Mar 29, 2014 at 2:42 AM, David Miller da...@davemloft.net wrote: From: Tom Gundersen t...@jklm.no Date: Fri, 28 Mar 2014 23:39:57 +0100 You mean coordinate with each other in userspace? If so, I still don't see how this can ever be anything else than fragile. It will depend on each userspace component actually opting in to whatever scheme we devise, and does so correctly. Isn't that essentially what dbus is? A way for seperate userland components to coordinate their activities? The protocol is not the problem. The issue is that this information only exists reliably in the kernel, so we need to get it from there somehow. I just simply don't like all of these ramdom keys getting added all over the place to guide udev behavior wrt. some other entity. Well, in this case udev is sort of doing a bit of the kernel's work, and it needs some information from the kernel to do it reliably. Another approach would be for the kernel to just assign predictable interface names to devices to begin with and we would never have to touch them. You have all the information so that would be relatively easy. The issue I see with that is that there are several ways to generate predictable names, and the user may want to chose between them, so this is arguably policy that should not be in the kernel. If you don't think that's a problem, I'd be happy to submit a patch to move all this logic from udev to the kernel, just let me know how you see it. Cheers, Tom -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 0/4] Provide netdev naming-policy via sysfs
From: Tom Gundersen t...@jklm.no Date: Sat, 29 Mar 2014 10:46:02 +0100 The issue I see with that is that there are several ways to generate predictable names, and the user may want to chose between them, so this is arguably policy that should not be in the kernel. If you don't think that's a problem, I'd be happy to submit a patch to move all this logic from udev to the kernel, just let me know how you see it. Unfortunately, we have already allowed this kind of thing for setting MAC addresses so I guess I'll have to allow your changes to be applied. But before I ask you to resubmit, do you have full buy-in from the udev folks for this facility? Thanks. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 0/4] Provide netdev naming-policy via sysfs
On Sat, Mar 29, 2014 at 8:37 PM, David Miller da...@davemloft.net wrote: From: Tom Gundersen t...@jklm.no Date: Sat, 29 Mar 2014 10:46:02 +0100 The issue I see with that is that there are several ways to generate predictable names, and the user may want to chose between them, so this is arguably policy that should not be in the kernel. If you don't think that's a problem, I'd be happy to submit a patch to move all this logic from udev to the kernel, just let me know how you see it. Unfortunately, we have already allowed this kind of thing for setting MAC addresses so I guess I'll have to allow your changes to be applied. But before I ask you to resubmit, do you have full buy-in from the udev folks for this facility? Absolutely, it is very useful to have. Today, there is no way for userland to distinguish explicitly requested and predictable names provided by tools, from unpredictable names composed by the kernel itself by adding an unpredictable enumeration number. It allows us the work around the common problems in general purpose Linux, where we have no strong dependencies, not necessarily central management, and loose coupling between components. This information will allow us to apply best-effort or common sense to the default udev device name policies, like: - leave the name alone if someone has asked explicitly for that name - leave the name alone if someone else has already renamed it after its first creation So, having that information in /sys would be very welcome from udev's point of view. Thanks, Kay -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 0/4] Provide netdev naming-policy via sysfs
From: Tom Gundersen Date: Fri, 28 Mar 2014 23:39:57 +0100 > You mean coordinate with each other in userspace? If so, I still don't > see how this can ever be anything else than fragile. It will depend on > each userspace component actually opting in to whatever scheme we > devise, and does so correctly. Isn't that essentially what dbus is? A way for seperate userland components to coordinate their activities? I just simply don't like all of these ramdom keys getting added all over the place to guide udev behavior wrt. some other entity. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 0/4] Provide netdev naming-policy via sysfs
On Fri, Mar 28, 2014 at 10:21 PM, David Miller wrote: > From: Tom Gundersen > Date: Fri, 28 Mar 2014 21:51:53 +0100 > >> On Fri, Mar 28, 2014 at 7:54 PM, David Miller wrote: >>> From: David Herrmann >>> Date: Wed, 26 Mar 2014 14:05:13 +0100 >>> The main use-case is to allow udev to skip applying reliable ifnames to virtual devices. For instance, if wifi-P2P devices are created, wpas already provides a suitable naming-policy and udev shouldn't touch these devices. Same is true for other virtual devices. >>> >>> This makes no sense at all. >>> >>> If udev should avoid applying names to wifi-P2P devices, that policy can >>> be instituted completely inside of udev. There is no need whatsoever >>> for kernel support. >>> >>> udev can look at the device type, and policies can be defined that key >>> off of that device type, entirely in userspace. >> >> Doing this in userspace sounds really wrong and fragile. >> >> In the case of wifi-P2P we could make it work, but for every type of >> device that is added to the kernel which is named from userspace, we >> would have to play catch-up in udev (and even after we do, new kernels >> on old userspace will never work in the expected way). > > Chronically we are finding hackish ways for seperate components in > userspace to coordinate their actions. > > You're right, doing this for every device type for every single attribute > that might better sucks. > > What's really needed is generic ways for seperate userspace components > to coordinate with eachother on issues like this. You mean coordinate with each other in userspace? If so, I still don't see how this can ever be anything else than fragile. It will depend on each userspace component actually opting in to whatever scheme we devise, and does so correctly. The kernel is the only one who can know where the names came from in a reliable way (no matter how crappy the userspace component who originally created or renamed the devices is). In udev we can ensure that what we do ourselves is sane, and we are happy to trust that what the kernel does is sane (and that the info it exposes to us is correct). However, we cannot really rely on each of the myriad of different components who may in various ways create/rename netdevs will manage to correctly hook into some synchronisation mechanism. Given that the kernel already has all the necessary info, and that the patch to expose it is so trivial, and that it is absolutely not clear at all that this can even be done in userspace (let alone being done in a sane way), I still struggle to see the reason for rejecting the patch... Or am I missing some obvious way we can solve this in userspace? Cheers, Tom -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 0/4] Provide netdev naming-policy via sysfs
From: Tom Gundersen Date: Fri, 28 Mar 2014 21:51:53 +0100 > On Fri, Mar 28, 2014 at 7:54 PM, David Miller wrote: >> From: David Herrmann >> Date: Wed, 26 Mar 2014 14:05:13 +0100 >> >>> The main use-case is to allow udev to skip applying reliable ifnames to >>> virtual >>> devices. For instance, if wifi-P2P devices are created, wpas already >>> provides a >>> suitable naming-policy and udev shouldn't touch these devices. Same is true >>> for >>> other virtual devices. >> >> This makes no sense at all. >> >> If udev should avoid applying names to wifi-P2P devices, that policy can >> be instituted completely inside of udev. There is no need whatsoever >> for kernel support. >> >> udev can look at the device type, and policies can be defined that key >> off of that device type, entirely in userspace. > > Doing this in userspace sounds really wrong and fragile. > > In the case of wifi-P2P we could make it work, but for every type of > device that is added to the kernel which is named from userspace, we > would have to play catch-up in udev (and even after we do, new kernels > on old userspace will never work in the expected way). Chronically we are finding hackish ways for seperate components in userspace to coordinate their actions. You're right, doing this for every device type for every single attribute that might better sucks. What's really needed is generic ways for seperate userspace components to coordinate with eachother on issues like this. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 0/4] Provide netdev naming-policy via sysfs
From: David Herrmann Date: Fri, 28 Mar 2014 20:34:47 +0100 > However, as mentioned in the discussions on v1, there're more > use-cases than that. Imagine a 3rd party initrd renames a > network-device early, if udev runs in the main system, we would rename > the device again. If we could detect the rename via NET_NAME_RENAMED, > we wouldn't break such setups. The only reason to rename devices in > udev is to get reliable names. If someone else already renamed a > device, we always expect them to provide better names than we do, so > udev should only touch devices that have kernel-enumerated names. > Of course, this can be fixed by requiring all the initrd developers to > somehow tag devices as already renamed. But this would replicate > information that the kernel already has. You want to use the kernel to facilitate communication between two userland components. Imagine if we had to do that for everything. Really, it's not a good reason, sorry. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 0/4] Provide netdev naming-policy via sysfs
On Fri, Mar 28, 2014 at 7:54 PM, David Miller wrote: > From: David Herrmann > Date: Wed, 26 Mar 2014 14:05:13 +0100 > >> The main use-case is to allow udev to skip applying reliable ifnames to >> virtual >> devices. For instance, if wifi-P2P devices are created, wpas already >> provides a >> suitable naming-policy and udev shouldn't touch these devices. Same is true >> for >> other virtual devices. > > This makes no sense at all. > > If udev should avoid applying names to wifi-P2P devices, that policy can > be instituted completely inside of udev. There is no need whatsoever > for kernel support. > > udev can look at the device type, and policies can be defined that key > off of that device type, entirely in userspace. Doing this in userspace sounds really wrong and fragile. In the case of wifi-P2P we could make it work, but for every type of device that is added to the kernel which is named from userspace, we would have to play catch-up in udev (and even after we do, new kernels on old userspace will never work in the expected way). Moreover, there are of course cases where knowing the type of device is not sufficient. Take 'ip link add type bridge' vs. 'ip link add dev bride5 type bridge'. They may both create a new bridge called 'bride5'. In the first case, we may reasonably want a policy in udev to rename the device to something better, but in the second case we probably want to leave it alone. >From userspace there is no way (that I know of) to determine if the name of a given device was picked by the kernel (i.e., more or less randomly) or by the userspace process that created it (i.e., probably for a good reason, so we should not touch it). Also the problems with third-party processes renaming devices which David outlined is a real problem that we run into in practice. We could of course dream up mechanisms for these processes to communicate to udev that they already renamed the device (and we have), but people will keep getting this wrong, so asking the kernel for this information just makes so much more sense. These patches seem to solve all the problems with network interface renaming really nicely once and for all, so would be a real shame if they don't go in. Cheers, Tom -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 0/4] Provide netdev naming-policy via sysfs
Hi On Fri, Mar 28, 2014 at 7:54 PM, David Miller wrote: > udev can look at the device type, and policies can be defined that key > off of that device type, entirely in userspace. Regarding wifi-P2P devices, udev can indeed use nl80211 to get the exact IF-type. An attribute would be much easier to read out, but I'm ok if we don't want to replicate that information. However, as mentioned in the discussions on v1, there're more use-cases than that. Imagine a 3rd party initrd renames a network-device early, if udev runs in the main system, we would rename the device again. If we could detect the rename via NET_NAME_RENAMED, we wouldn't break such setups. The only reason to rename devices in udev is to get reliable names. If someone else already renamed a device, we always expect them to provide better names than we do, so udev should only touch devices that have kernel-enumerated names. Of course, this can be fixed by requiring all the initrd developers to somehow tag devices as already renamed. But this would replicate information that the kernel already has. Another example are dynamically created devices via RTM_NEWLINK. The if-names are provided by user-space and udev should never try to do any magic renaming on them (why would we? you can just easily fix the code that created the device). So it turns out, all we want to know is whether an interface-name was chosen by the kernel via plain, simple enumeration, or whether it has a user-space origin. Only in the former case we want to rename the device. The name_assign_type attribute tells us exactly where a name comes from and thus avoids maintaining blacklists in user-space that skip renaming on such devices. I'm sorry, but I cannot see why such blacklists (or whitelists) are preferred over a sysfs attribute. Thanks David -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 0/4] Provide netdev naming-policy via sysfs
From: David Herrmann Date: Wed, 26 Mar 2014 14:05:13 +0100 > The main use-case is to allow udev to skip applying reliable ifnames to > virtual > devices. For instance, if wifi-P2P devices are created, wpas already provides > a > suitable naming-policy and udev shouldn't touch these devices. Same is true > for > other virtual devices. This makes no sense at all. If udev should avoid applying names to wifi-P2P devices, that policy can be instituted completely inside of udev. There is no need whatsoever for kernel support. udev can look at the device type, and policies can be defined that key off of that device type, entirely in userspace. I'm not applying this patch series, sorry. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 0/4] Provide netdev naming-policy via sysfs
From: David Herrmann dh.herrm...@gmail.com Date: Wed, 26 Mar 2014 14:05:13 +0100 The main use-case is to allow udev to skip applying reliable ifnames to virtual devices. For instance, if wifi-P2P devices are created, wpas already provides a suitable naming-policy and udev shouldn't touch these devices. Same is true for other virtual devices. This makes no sense at all. If udev should avoid applying names to wifi-P2P devices, that policy can be instituted completely inside of udev. There is no need whatsoever for kernel support. udev can look at the device type, and policies can be defined that key off of that device type, entirely in userspace. I'm not applying this patch series, sorry. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 0/4] Provide netdev naming-policy via sysfs
Hi On Fri, Mar 28, 2014 at 7:54 PM, David Miller da...@davemloft.net wrote: udev can look at the device type, and policies can be defined that key off of that device type, entirely in userspace. Regarding wifi-P2P devices, udev can indeed use nl80211 to get the exact IF-type. An attribute would be much easier to read out, but I'm ok if we don't want to replicate that information. However, as mentioned in the discussions on v1, there're more use-cases than that. Imagine a 3rd party initrd renames a network-device early, if udev runs in the main system, we would rename the device again. If we could detect the rename via NET_NAME_RENAMED, we wouldn't break such setups. The only reason to rename devices in udev is to get reliable names. If someone else already renamed a device, we always expect them to provide better names than we do, so udev should only touch devices that have kernel-enumerated names. Of course, this can be fixed by requiring all the initrd developers to somehow tag devices as already renamed. But this would replicate information that the kernel already has. Another example are dynamically created devices via RTM_NEWLINK. The if-names are provided by user-space and udev should never try to do any magic renaming on them (why would we? you can just easily fix the code that created the device). So it turns out, all we want to know is whether an interface-name was chosen by the kernel via plain, simple enumeration, or whether it has a user-space origin. Only in the former case we want to rename the device. The name_assign_type attribute tells us exactly where a name comes from and thus avoids maintaining blacklists in user-space that skip renaming on such devices. I'm sorry, but I cannot see why such blacklists (or whitelists) are preferred over a sysfs attribute. Thanks David -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 0/4] Provide netdev naming-policy via sysfs
On Fri, Mar 28, 2014 at 7:54 PM, David Miller da...@davemloft.net wrote: From: David Herrmann dh.herrm...@gmail.com Date: Wed, 26 Mar 2014 14:05:13 +0100 The main use-case is to allow udev to skip applying reliable ifnames to virtual devices. For instance, if wifi-P2P devices are created, wpas already provides a suitable naming-policy and udev shouldn't touch these devices. Same is true for other virtual devices. This makes no sense at all. If udev should avoid applying names to wifi-P2P devices, that policy can be instituted completely inside of udev. There is no need whatsoever for kernel support. udev can look at the device type, and policies can be defined that key off of that device type, entirely in userspace. Doing this in userspace sounds really wrong and fragile. In the case of wifi-P2P we could make it work, but for every type of device that is added to the kernel which is named from userspace, we would have to play catch-up in udev (and even after we do, new kernels on old userspace will never work in the expected way). Moreover, there are of course cases where knowing the type of device is not sufficient. Take 'ip link add type bridge' vs. 'ip link add dev bride5 type bridge'. They may both create a new bridge called 'bride5'. In the first case, we may reasonably want a policy in udev to rename the device to something better, but in the second case we probably want to leave it alone. From userspace there is no way (that I know of) to determine if the name of a given device was picked by the kernel (i.e., more or less randomly) or by the userspace process that created it (i.e., probably for a good reason, so we should not touch it). Also the problems with third-party processes renaming devices which David outlined is a real problem that we run into in practice. We could of course dream up mechanisms for these processes to communicate to udev that they already renamed the device (and we have), but people will keep getting this wrong, so asking the kernel for this information just makes so much more sense. These patches seem to solve all the problems with network interface renaming really nicely once and for all, so would be a real shame if they don't go in. Cheers, Tom -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 0/4] Provide netdev naming-policy via sysfs
From: David Herrmann dh.herrm...@gmail.com Date: Fri, 28 Mar 2014 20:34:47 +0100 However, as mentioned in the discussions on v1, there're more use-cases than that. Imagine a 3rd party initrd renames a network-device early, if udev runs in the main system, we would rename the device again. If we could detect the rename via NET_NAME_RENAMED, we wouldn't break such setups. The only reason to rename devices in udev is to get reliable names. If someone else already renamed a device, we always expect them to provide better names than we do, so udev should only touch devices that have kernel-enumerated names. Of course, this can be fixed by requiring all the initrd developers to somehow tag devices as already renamed. But this would replicate information that the kernel already has. You want to use the kernel to facilitate communication between two userland components. Imagine if we had to do that for everything. Really, it's not a good reason, sorry. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 0/4] Provide netdev naming-policy via sysfs
From: Tom Gundersen t...@jklm.no Date: Fri, 28 Mar 2014 21:51:53 +0100 On Fri, Mar 28, 2014 at 7:54 PM, David Miller da...@davemloft.net wrote: From: David Herrmann dh.herrm...@gmail.com Date: Wed, 26 Mar 2014 14:05:13 +0100 The main use-case is to allow udev to skip applying reliable ifnames to virtual devices. For instance, if wifi-P2P devices are created, wpas already provides a suitable naming-policy and udev shouldn't touch these devices. Same is true for other virtual devices. This makes no sense at all. If udev should avoid applying names to wifi-P2P devices, that policy can be instituted completely inside of udev. There is no need whatsoever for kernel support. udev can look at the device type, and policies can be defined that key off of that device type, entirely in userspace. Doing this in userspace sounds really wrong and fragile. In the case of wifi-P2P we could make it work, but for every type of device that is added to the kernel which is named from userspace, we would have to play catch-up in udev (and even after we do, new kernels on old userspace will never work in the expected way). Chronically we are finding hackish ways for seperate components in userspace to coordinate their actions. You're right, doing this for every device type for every single attribute that might better sucks. What's really needed is generic ways for seperate userspace components to coordinate with eachother on issues like this. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 0/4] Provide netdev naming-policy via sysfs
On Fri, Mar 28, 2014 at 10:21 PM, David Miller da...@davemloft.net wrote: From: Tom Gundersen t...@jklm.no Date: Fri, 28 Mar 2014 21:51:53 +0100 On Fri, Mar 28, 2014 at 7:54 PM, David Miller da...@davemloft.net wrote: From: David Herrmann dh.herrm...@gmail.com Date: Wed, 26 Mar 2014 14:05:13 +0100 The main use-case is to allow udev to skip applying reliable ifnames to virtual devices. For instance, if wifi-P2P devices are created, wpas already provides a suitable naming-policy and udev shouldn't touch these devices. Same is true for other virtual devices. This makes no sense at all. If udev should avoid applying names to wifi-P2P devices, that policy can be instituted completely inside of udev. There is no need whatsoever for kernel support. udev can look at the device type, and policies can be defined that key off of that device type, entirely in userspace. Doing this in userspace sounds really wrong and fragile. In the case of wifi-P2P we could make it work, but for every type of device that is added to the kernel which is named from userspace, we would have to play catch-up in udev (and even after we do, new kernels on old userspace will never work in the expected way). Chronically we are finding hackish ways for seperate components in userspace to coordinate their actions. You're right, doing this for every device type for every single attribute that might better sucks. What's really needed is generic ways for seperate userspace components to coordinate with eachother on issues like this. You mean coordinate with each other in userspace? If so, I still don't see how this can ever be anything else than fragile. It will depend on each userspace component actually opting in to whatever scheme we devise, and does so correctly. The kernel is the only one who can know where the names came from in a reliable way (no matter how crappy the userspace component who originally created or renamed the devices is). In udev we can ensure that what we do ourselves is sane, and we are happy to trust that what the kernel does is sane (and that the info it exposes to us is correct). However, we cannot really rely on each of the myriad of different components who may in various ways create/rename netdevs will manage to correctly hook into some synchronisation mechanism. Given that the kernel already has all the necessary info, and that the patch to expose it is so trivial, and that it is absolutely not clear at all that this can even be done in userspace (let alone being done in a sane way), I still struggle to see the reason for rejecting the patch... Or am I missing some obvious way we can solve this in userspace? Cheers, Tom -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 0/4] Provide netdev naming-policy via sysfs
From: Tom Gundersen t...@jklm.no Date: Fri, 28 Mar 2014 23:39:57 +0100 You mean coordinate with each other in userspace? If so, I still don't see how this can ever be anything else than fragile. It will depend on each userspace component actually opting in to whatever scheme we devise, and does so correctly. Isn't that essentially what dbus is? A way for seperate userland components to coordinate their activities? I just simply don't like all of these ramdom keys getting added all over the place to guide udev behavior wrt. some other entity. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v5 0/4] Provide netdev naming-policy via sysfs
Hi This is v5 of the netdev naming-policy series. You can find v4 here: http://article.gmane.org/gmane.linux.kernel/1668161 Changes since v4: - none This series implements a new sysfs attribute for netdevs called "name_assign_type". It provides an integer that describes where an interface name comes from. See Patch #1 for a description of this attribute. It is modelled after the existing "addr_assign_type" attribute. The main use-case is to allow udev to skip applying reliable ifnames to virtual devices. For instance, if wifi-P2P devices are created, wpas already provides a suitable naming-policy and udev shouldn't touch these devices. Same is true for other virtual devices. The idea is that if a device-name was provided by user-space, we should always prefer fixing this naming-policy instead of making udev rename the device. For kernel provided names that's hardly possible, though. Providing the naming-policy source via sysfs is thus a simple way to see whether renames are needed. Additionally, this field allows to detect whether a netdev has been manually renamed, which is quite useful for debugging and during crash-recovery. Furthermore, it fixes real udev bugs if a netdev is already renamed in the initrd and udev only runs in the real root. Detecting renames avoids overwriting custom user provided names. Thanks David David Herrmann (4): net: add name_assign_type netdev attribute mac80211: set NET_NAME_USER for user-space created ifs ath6kl: set NET_NAME_USER for P2P ifs brcmfmac: set NET_NAME_USER for P2P ifs drivers/net/wireless/ath/ath6kl/cfg80211.c| 5 - drivers/net/wireless/ath/ath6kl/cfg80211.h| 1 + drivers/net/wireless/ath/ath6kl/core.c| 4 ++-- drivers/net/wireless/brcm80211/brcmfmac/p2p.c | 1 + include/linux/netdevice.h | 2 ++ include/uapi/linux/netdevice.h| 4 net/core/dev.c| 7 +++ net/core/net-sysfs.c | 2 ++ net/core/rtnetlink.c | 2 ++ net/mac80211/cfg.c| 2 +- net/mac80211/ieee80211_i.h| 1 + net/mac80211/iface.c | 2 ++ net/mac80211/main.c | 2 +- 13 files changed, 30 insertions(+), 5 deletions(-) -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v5 0/4] Provide netdev naming-policy via sysfs
Hi This is v5 of the netdev naming-policy series. You can find v4 here: http://article.gmane.org/gmane.linux.kernel/1668161 Changes since v4: - none This series implements a new sysfs attribute for netdevs called name_assign_type. It provides an integer that describes where an interface name comes from. See Patch #1 for a description of this attribute. It is modelled after the existing addr_assign_type attribute. The main use-case is to allow udev to skip applying reliable ifnames to virtual devices. For instance, if wifi-P2P devices are created, wpas already provides a suitable naming-policy and udev shouldn't touch these devices. Same is true for other virtual devices. The idea is that if a device-name was provided by user-space, we should always prefer fixing this naming-policy instead of making udev rename the device. For kernel provided names that's hardly possible, though. Providing the naming-policy source via sysfs is thus a simple way to see whether renames are needed. Additionally, this field allows to detect whether a netdev has been manually renamed, which is quite useful for debugging and during crash-recovery. Furthermore, it fixes real udev bugs if a netdev is already renamed in the initrd and udev only runs in the real root. Detecting renames avoids overwriting custom user provided names. Thanks David David Herrmann (4): net: add name_assign_type netdev attribute mac80211: set NET_NAME_USER for user-space created ifs ath6kl: set NET_NAME_USER for P2P ifs brcmfmac: set NET_NAME_USER for P2P ifs drivers/net/wireless/ath/ath6kl/cfg80211.c| 5 - drivers/net/wireless/ath/ath6kl/cfg80211.h| 1 + drivers/net/wireless/ath/ath6kl/core.c| 4 ++-- drivers/net/wireless/brcm80211/brcmfmac/p2p.c | 1 + include/linux/netdevice.h | 2 ++ include/uapi/linux/netdevice.h| 4 net/core/dev.c| 7 +++ net/core/net-sysfs.c | 2 ++ net/core/rtnetlink.c | 2 ++ net/mac80211/cfg.c| 2 +- net/mac80211/ieee80211_i.h| 1 + net/mac80211/iface.c | 2 ++ net/mac80211/main.c | 2 +- 13 files changed, 30 insertions(+), 5 deletions(-) -- 1.9.1 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
