On 14.03.2017 14:43, Zbigniew Jędrzejewski-Szmek wrote:
On Tue, Mar 14, 2017 at 06:39:29AM +0100, poma wrote:
On 13.03.2017 21:37, Stephen Morris wrote: [...]
In fact, for me, Fedora's naming convention raises more questions than it answers. Without knowing anything about the internal hardware design of a motherboard, how is a usb port on a pci bus, I would expect pci ports to be on a pci bus and usb ports to be on a usb bus, and relative to usb ports I would expect there to be a separate bus for usb 2 and usb 3 ports.
USB bus is a PCI device connected through the PCI bus. So the "geographical location" includes first the information where to find the USB bus, and then where to find the USB device starting from that.
dmesg -t | grep wl -m1 r92su 1-3:1.0 wlp0s2f1u3: renamed from wlan0
wlp0s2f1u3 wl p0 s2 f1 u3 wl-wlan p-bus=0 s-slot=2 f-function=1 u-port=3
So this USB bus in this case is multi-function device in slot 2 of PCI bus 0. Different functions probably correspond to different USB hubs, and the wireless card happens to be connected underneath function 1.
I don't think you're supposed to be able to guess the name on your own. Rather, you have a card, and you know that it has this stable name. If the card dies, and you replace it with a new one (in the same socket), the name will not change.
lsusb Bus 001 Device 003: ...
lsusb -t /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/6p, 480M |__ Port 3: Dev 3, If 0, Class=Vendor Specific Class, Driver=r92su, 480M
ls /sys/devices/pci0000:00/0000:00:02.1/usb1/1-3/1-3:1.0/net/ wlp0s2f1u3
lspci -d ::0c03 00:02.1 USB controller: ... 00 02 1 <bus>:<device>.<func>
udevadm info -q env /sys/class/net/wlp0s2f1u3 | grep PATH DEVPATH=/devices/pci0000:00/0000:00:02.1/usb1/1-3/1-3:1.0/net/wlp0s2f1u3 ID_NET_NAME_PATH=wlp0s2f1u3 ID_PATH=pci-0000:00:02.1-usb-0:3:1.0 ID_PATH_TAG=pci-0000_00_02_1-usb-0_3_1_0
udevadm info -a -p /sys/class/net/wlp0s2f1u3 | grep looking -A 3 looking at device '/devices/pci0000:00/0000:00:02.1/usb1/1-3/1-3:1.0/net/wlp0s2f1u3': KERNEL=="wlp0s2f1u3" SUBSYSTEM=="net" DRIVER=="" -- looking at parent device '/devices/pci0000:00/0000:00:02.1/usb1/1-3/1-3:1.0': KERNELS=="1-3:1.0" SUBSYSTEMS=="usb" DRIVERS=="r92su" -- looking at parent device '/devices/pci0000:00/0000:00:02.1/usb1/1-3': KERNELS=="1-3" SUBSYSTEMS=="usb" DRIVERS=="usb" -- looking at parent device '/devices/pci0000:00/0000:00:02.1/usb1': KERNELS=="usb1" SUBSYSTEMS=="usb" DRIVERS=="usb" -- looking at parent device '/devices/pci0000:00/0000:00:02.1': KERNELS=="0000:00:02.1" SUBSYSTEMS=="pci" DRIVERS=="ehci-pci" -- looking at parent device '/devices/pci0000:00': KERNELS=="pci0000:00" SUBSYSTEMS=="" DRIVERS==""
Ref. https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfac... https://github.com/systemd/systemd/blob/master/src/udev/udev-builtin-net_id....
- [P<domain>]p<bus>s<slot>[f<function>][u<port>][..][c<config>][i<interface>]
— USB port number chainHTH, Zbyszek
Yeah, the emphasis is on consistency of names of network interfaces. Thank you.
On Tue, 14 Mar 2017 17:01:04 +0100 poma wrote:
Yeah, the emphasis is on consistency of names of network interfaces.
And the consistent names change every single time some developer decides he just has to rewrite the algorithm to make it better, or systemd decides to engluph yet another component and not be backward compatible, or a kernel developer gets a new motherboard where the scheme doesn't work and his fix has the side effect of changing the names on thousands of existing systems, etc.
There have been at least 3 different "immutable" name schemes in the short time the whole concept has existed.
I finally decided to eradicate it and go back to eth0 and friends because it was infinitely more reliable than having to discover yet another naming scheme in every damn release.
Now my only problem will be that they'll probably keep changing the name of the kernel option to disable it :-).
On 03/14/2017 09:16 AM, Tom Horsley wrote:
Now my only problem will be that they'll probably keep changing the name of the kernel option to disable it :-).
More likely they'll just remove it because they know better than the people who actually use their software.
On 03/14/2017 09:16 AM, Tom Horsley wrote:
On Tue, 14 Mar 2017 17:01:04 +0100 poma wrote:
Yeah, the emphasis is on consistency of names of network interfaces.
And the consistent names change every single time some developer decides he just has to rewrite the algorithm to make it better, or systemd decides to engluph yet another component and not be backward compatible, or a kernel developer gets a new motherboard where the scheme doesn't work and his fix has the side effect of changing the names on thousands of existing systems, etc.
There have been at least 3 different "immutable" name schemes in the short time the whole concept has existed.
I finally decided to eradicate it and go back to eth0 and friends because it was infinitely more reliable than having to discover yet another naming scheme in every damn release.
Now my only problem will be that they'll probably keep changing the name of the kernel option to disable it :-).
It is quite difficult to come up with an immutable name that would be consistent with every hardware configuration possible. Ubuntu's concept of using the MAC address is fine...until you use multiple NICs in a bond where the MAC address of the first NIC is cloned onto the slaves to simplify ARP and such (or other such MAC-cloning scenarios).
Fedora's idea of bus/slot/device[/subunit] is fine as well...until the bus scan changes due to the addition of a new device into the bus. There was a time where running a kernel on a Dell 2950 (4U) box would enumerate the motherboard NICs first, followed by any in the external PCI bus. Running the SAME kernel on a Dell 1950 (2U) box would enumerate the external PCI bus NICs first, then the motherboard NICs. Damned frustrating!
Back in the day, Sun used the MAC address of the NIC as the unique system identifier for a machine. If the NIC ever had to be replaced (which happened fairly often), then all of your software licenses were invalidated as they were tied to that MAC address. Grrrr!
Like I said, it's damned difficult to come up with something. If you have a better idea, then submit it to the various kernel groups. This is an issue that's been plaguing them for a long time. In the interim, come up with your own udev rules and swap them around from distro to distro. That's the beauty of Linux...you can tweak it to match what you want--up to a point (oh, I'd love to go off on systemd again...). ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer, AllDigital ricks@alldigital.com - - AIM/Skype: therps2 ICQ: 226437340 Yahoo: origrps2 - - - - Fear is finding a ".vbs" script in your Inbox - ----------------------------------------------------------------------
On Tue, 14 Mar 2017 09:43:45 -0700 Rick Stevens wrote:
Like I said, it's damned difficult to come up with something. If you have a better idea, then submit it to the various kernel groups.
I do have a better idea: Go back to the way it was when you could use udev to permanently assign names to interfaces :-).
As you have just shown it is impossible to get it "right" but before they "fixed" it, you could at least get it to remain consistent with the udev rules.
Stop trying to solve impossible problems.
The current naming scheme works for the case of motherboard replacements were the names and pci buses stay the same but the mac addresses change.
I was previously using a static udev rule using bus-ids to force the eth* devices to be consistent across motherboard replacements and chassis swaps. We had separate similar udev rules for each "model" we used. A static naming schem based on bus-id does eliminate the need for the udev rule based on busid.
Note that all previous default udev schemes used in all versions I had experience with were *CRAP* as on a motherboard replacement (exact same model of motherboard) the new devices ended up being ethn+1....were n was the number of original cards several of which are no longer in there.
I did have one home motherboard were adding a PCI card resulted in the bus-id changing but I more count that as a bad bios as outside of that motherboard I have never seen the bus-id chaned.
Using mac address fails on card replacement without fighting with the default generated rules and system, were as the static naming just works on card and motherboard replacements. And in the enterprise card and motherboard replacements happen often.
On Tue, Mar 14, 2017 at 12:25 PM, Tom Horsley horsley1953@gmail.com wrote:
On Tue, 14 Mar 2017 09:43:45 -0700 Rick Stevens wrote:
Like I said, it's damned difficult to come up with something. If you have a better idea, then submit it to the various kernel groups.
I do have a better idea: Go back to the way it was when you could use udev to permanently assign names to interfaces :-).
As you have just shown it is impossible to get it "right" but before they "fixed" it, you could at least get it to remain consistent with the udev rules.
Stop trying to solve impossible problems. _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org
On 3/15/17 3:25 AM, Tom Horsley wrote:
On Tue, 14 Mar 2017 09:43:45 -0700 Rick Stevens wrote:
Like I said, it's damned difficult to come up with something. If you have a better idea, then submit it to the various kernel groups.
I do have a better idea: Go back to the way it was when you could use udev to permanently assign names to interfaces :-).
As you have just shown it is impossible to get it "right" but before they "fixed" it, you could at least get it to remain consistent with the udev rules.
Stop trying to solve impossible problems.
I have several questions around the naming convention.
My usb wireless adapter is named wlp3s0u2, hence the naming convention is saying the adapter is usb device 3. I do have 3 usb devices connected. Two of the devices are usb 2 and the adapter is usb 3, hence when the device enumeration is done to determine what exists, what controls whether usb 2 devices are enumerated first , is it software or the motherboard? Assuming the naming convention is based on enumeration which it may not be given that, I have 2 usb 3 slots on the front of my machine and, if on the running system I unplug my wireless adapter and plug it into the second slot, when the system recognizes the device again the name changes to wlp3s0u1. Also I have 2 usb 2 slots on the front of my machine, and if I do the same thing to my adapter and unplug it from the usb 3 slot and plug it into the second usb 2 slot the name changes to wlp0s19f2u3, hence what does the naming convention actually represent?
As I said above I have 3 usb devices, the other 2 are a keyboard and the transmitter for my wireless mouse. How do I find what the naming convention for those two devices is, in terms of what they are actually named?
Lastly, if I plug a flash driver into the usb 3 slot where my wireless adapter was what name does it inherit and how do I find out?
regards, Steve
users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org
On 03/14/2017 02:27 PM, Stephen Morris wrote:
On 3/15/17 3:25 AM, Tom Horsley wrote:
On Tue, 14 Mar 2017 09:43:45 -0700 Rick Stevens wrote:
Like I said, it's damned difficult to come up with something. If you have a better idea, then submit it to the various kernel groups.
I do have a better idea: Go back to the way it was when you could use udev to permanently assign names to interfaces :-).
As you have just shown it is impossible to get it "right" but before they "fixed" it, you could at least get it to remain consistent with the udev rules.
Stop trying to solve impossible problems.
I have several questions around the naming convention.
My usb wireless adapter is named wlp3s0u2, hence the naming convention is saying the adapter is usb device 3. I do have 3 usb devices connected. Two of the devices are usb 2 and the adapter is usb 3, hence when the device enumeration is done to determine what exists, what controls whether usb 2 devices are enumerated first , is it software or the motherboard?
Remember, we're talking about network interfaces here and the naming conventions we've been discussing here ONLY affects network interfaces.
Assuming the naming convention is based on enumerationwhich it may not be given that, I have 2 usb 3 slots on the front of my machine and, if on the running system I unplug my wireless adapter and plug it into the second slot, when the system recognizes the device again the name changes to wlp3s0u1. Also I have 2 usb 2 slots on the front of my machine, and if I do the same thing to my adapter and unplug it from the usb 3 slot and plug it into the second usb 2 slot the name changes to wlp0s19f2u3, hence what does the naming convention actually represent?
I'm not sure. It sounds like all the USB hubs in your machine interface through PCI slot 3. I would have expected that the various hubs would have different "s" numbers (e.g. one hub on p3s0, one on p3s1, etc.).
As I said above I have 3 usb devices, the other 2 are a keyboard and the transmitter for my wireless mouse. How do I find what the naming convention for those two devices is, in terms of what they are actually named?
They'd show up in the dmesg log, but they will NOT be named things like "wlp3". Again, that's just for wireless NICs. I have a Logitech wireless keyboard and mouse and this is how they appear in dmesg:
[ 2.556799] logitech 0003:046D:C517.0001: input,hidraw1: USB HID v1.10 Keyboard [Logitech USB Receiver] on usb-0000:00:14.0-5/input0 [ 2.608866] logitech 0003:046D:C517.0002: input,hiddev0,hidraw2: USB HID v1.10 Mouse [Logitech USB Receiver] on usb-0000:00:14.0-5/input1
Lastly, if I plug a flash driver into the usb 3 slot where my wireless adapter was what name does it inherit and how do I find out?
It would most likely be /dev/sdX, where "X" was the next sequential disk number available at the time you plugged the device in.
regards, Steve
users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org
users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org
On 14.03.2017 17:16, Tom Horsley wrote:
And the consistent names change every single time some developer decides he just has to rewrite the algorithm to make it better, or systemd decides to engluph yet another component and not be backward compatible, or a kernel developer gets a new motherboard where the scheme doesn't work and his fix has the side effect of changing the names on thousands of existing systems, etc.
There have been at least 3 different "immutable" name schemes in the short time the whole concept has existed.
I finally decided to eradicate it and go back to eth0 and friends because it was infinitely more reliable than having to discover yet another naming scheme in every damn release.
Now my only problem will be that they'll probably keep changing the name of the kernel option to disable it :-).
This sounds quite disturbing, can someone from the systemd and kernel campus comment here, as Tom claims, whether these are the facts?
On 3/15/17 11:04 AM, Rick Stevens wrote:
On 03/14/2017 02:27 PM, Stephen Morris wrote:
On 3/15/17 3:25 AM, Tom Horsley wrote:
On Tue, 14 Mar 2017 09:43:45 -0700 Rick Stevens wrote:
Like I said, it's damned difficult to come up with something. If you have a better idea, then submit it to the various kernel groups.
I do have a better idea: Go back to the way it was when you could use udev to permanently assign names to interfaces :-).
As you have just shown it is impossible to get it "right" but before they "fixed" it, you could at least get it to remain consistent with the udev rules.
Stop trying to solve impossible problems.
I have several questions around the naming convention.
My usb wireless adapter is named wlp3s0u2, hence the naming convention is saying the adapter is usb device 3. I do have 3 usb devices connected. Two of the devices are usb 2 and the adapter is usb 3, hence when the device enumeration is done to determine what exists, what controls whether usb 2 devices are enumerated first , is it software or the motherboard?
Remember, we're talking about network interfaces here and the naming conventions we've been discussing here ONLY affects network interfaces.
So am I. I thought the naming convention of 'u2' indicated that the wifi adapter was the third usb device (which makes sense because I do have 3 usb devices plugged in to the machine) hence what determined the adapter was the third usb device, given that I would have thought the usb 3 interfaces would have been polled for device discovery before the usb 2 interfaces. But having said this the fact that the device name changed to 'u1' when I plugged the device into the other cable connected usb 3 slot indicates that the 'u' part of the name is the usb slot number not the device number.
Assuming the naming convention is based on enumerationwhich it may not be given that, I have 2 usb 3 slots on the front of my machine and, if on the running system I unplug my wireless adapter and plug it into the second slot, when the system recognizes the device again the name changes to wlp3s0u1. Also I have 2 usb 2 slots on the front of my machine, and if I do the same thing to my adapter and unplug it from the usb 3 slot and plug it into the second usb 2 slot the name changes to wlp0s19f2u3, hence what does the naming convention actually represent?
I'm not sure. It sounds like all the USB hubs in your machine interface through PCI slot 3. I would have expected that the various hubs would have different "s" numbers (e.g. one hub on p3s0, one on p3s1, etc.).
What you expected to be the situation is the case between the usb 2 and usb 3 ports, they are on different pci slots, at least according to the naming convention. But what I don't understand is why the vastly different name when the device is plugged into a usb 2 slot, I would have expected the name to be wlp0s19u3. I fully understand that a usb 3 device plugged into a usb 2 port is going to lose functionality, but why does the naming convention need to specify that, and what functionality does the 'f2' indicate is being provided by the device?
As I said above I have 3 usb devices, the other 2 are a keyboard and the transmitter for my wireless mouse. How do I find what the naming convention for those two devices is, in terms of what they are actually named?
They'd show up in the dmesg log, but they will NOT be named things like "wlp3". Again, that's just for wireless NICs. I have a Logitech wireless keyboard and mouse and this is how they appear in dmesg:
[ 2.556799] logitech 0003:046D:C517.0001: input,hidraw1: USB HID v1.10 Keyboard [Logitech USB Receiver] on usb-0000:00:14.0-5/input0 [ 2.608866] logitech 0003:046D:C517.0002: input,hiddev0,hidraw2: USB HID v1.10 Mouse [Logitech USB Receiver] on usb-0000:00:14.0-5/input1
Lastly, if I plug a flash driver into the usb 3 slot where my wireless adapter was what name does it inherit and how do I find out?
It would most likely be /dev/sdX, where "X" was the next sequential disk number available at the time you plugged the device in.
I was under the impression from other responses to this thread that all devices had a standard naming convention, which I thought was similar to the network device naming convention, hence, if my impression was correct, what is that naming convention for other devices?
This also leads me down another path, if I plug into my machine my flash disk, my digital SLR camera and my digital video camera, the flask disk is auto mounted under /media and the other two are auto mounted under /run, why are they all not mounted under /media or /run, and, what determines where they will be mounted and what is different between them that causes them to be mounted differently?
I also apologize for all the questions, I'm just trying to understand how the distribution works under the covers so that I can better manage my system.
regards, Steve
regards, Steve
users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org
users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org
On 03/19/2017 01:36 PM, Stephen Morris wrote:
On 3/15/17 11:04 AM, Rick Stevens wrote:
On 03/14/2017 02:27 PM, Stephen Morris wrote:
On 3/15/17 3:25 AM, Tom Horsley wrote:
On Tue, 14 Mar 2017 09:43:45 -0700 Rick Stevens wrote:
Like I said, it's damned difficult to come up with something. If you have a better idea, then submit it to the various kernel groups.
I do have a better idea: Go back to the way it was when you could use udev to permanently assign names to interfaces :-).
As you have just shown it is impossible to get it "right" but before they "fixed" it, you could at least get it to remain consistent with the udev rules.
Stop trying to solve impossible problems.
I have several questions around the naming convention.
My usb wireless adapter is named wlp3s0u2, hence the naming convention is saying the adapter is usb device 3. I do have 3 usb devices connected. Two of the devices are usb 2 and the adapter is usb 3, hence when the device enumeration is done to determine what exists, what controls whether usb 2 devices are enumerated first , is it software or the motherboard?
Remember, we're talking about network interfaces here and the naming conventions we've been discussing here ONLY affects network interfaces.
So am I. I thought the naming convention of 'u2' indicated that the wifi adapter was the third usb device (which makes sense because I do have 3 usb devices plugged in to the machine) hence what determined the adapter was the third usb device, given that I would have thought the usb 3 interfaces would have been polled for device discovery before the usb 2 interfaces. But having said this the fact that the device name changed to 'u1' when I plugged the device into the other cable connected usb 3 slot indicates that the 'u' part of the name is the usb slot number not the device number.
Assuming the naming convention is based on enumerationwhich it may not be given that, I have 2 usb 3 slots on the front of my machine and, if on the running system I unplug my wireless adapter and plug it into the second slot, when the system recognizes the device again the name changes to wlp3s0u1. Also I have 2 usb 2 slots on the front of my machine, and if I do the same thing to my adapter and unplug it from the usb 3 slot and plug it into the second usb 2 slot the name changes to wlp0s19f2u3, hence what does the naming convention actually represent?
I'm not sure. It sounds like all the USB hubs in your machine interface through PCI slot 3. I would have expected that the various hubs would have different "s" numbers (e.g. one hub on p3s0, one on p3s1, etc.).
What you expected to be the situation is the case between the usb 2 and usb 3 ports, they are on different pci slots, at least according to the naming convention. But what I don't understand is why the vastly different name when the device is plugged into a usb 2 slot, I would have expected the name to be wlp0s19u3. I fully understand that a usb 3 device plugged into a usb 2 port is going to lose functionality, but why does the naming convention need to specify that, and what functionality does the 'f2' indicate is being provided by the device?
I can't answer why the "f2" appears. My interpretations are based on what I recall was explained when this whole "NIC-named-after-PCI-bus- scanning" thing started with (I think it was) kernel V2.6 or V3.x. Can't recall, it was a long time ago, I'm getting old and my brain is getting full. :-)
As I said above I have 3 usb devices, the other 2 are a keyboard and the transmitter for my wireless mouse. How do I find what the naming convention for those two devices is, in terms of what they are actually named?
They'd show up in the dmesg log, but they will NOT be named things like "wlp3". Again, that's just for wireless NICs. I have a Logitech wireless keyboard and mouse and this is how they appear in dmesg:
[ 2.556799] logitech 0003:046D:C517.0001: input,hidraw1: USB HID v1.10 Keyboard [Logitech USB Receiver] on usb-0000:00:14.0-5/input0 [ 2.608866] logitech 0003:046D:C517.0002: input,hiddev0,hidraw2: USB HID v1.10 Mouse [Logitech USB Receiver] on usb-0000:00:14.0-5/input1
Lastly, if I plug a flash driver into the usb 3 slot where my wireless adapter was what name does it inherit and how do I find out?
It would most likely be /dev/sdX, where "X" was the next sequential disk number available at the time you plugged the device in.
I was under the impression from other responses to this thread that all devices had a standard naming convention, which I thought was similar to the network device naming convention, hence, if my impression was correct, what is that naming convention for other devices?
This also leads me down another path, if I plug into my machine my flash disk, my digital SLR camera and my digital video camera, the flask disk is auto mounted under /media and the other two are auto mounted under /run, why are they all not mounted under /media or /run, and, what determines where they will be mounted and what is different between them that causes them to be mounted differently?
Well, the flash disk is identified by the system as a mass storage device. By default definition, mass storage devices are automounted under "/media" (since, well, that's what they are...media). Your cameras don't generally use a standard disk-style interface and aren't considered mass storage devices per se, so they get auto mounted under "/run" (since there's usually some middleware such as "mtpfs" between the camera and the kernel).
Automounting is generally handled by your desktop environment, not udev itself. udev sees the insertion, sends out a "gee, I see a new device" DBUS message, which your desktop manager picks up and either ignores or does whatever it's configured to do. Theoretically, you can go into your desktop config and tell it to automount your cameras under "~/fradleybard" and it'll do it (assuming you have a "fradleybard" directory under your home directory and it's writable).
I personally don't like automounts and don't have them enabled (I use XFCE and this is controlled under "Applications->Settings->Removable Drives and Media").
I also apologize for all the questions, I'm just trying to understand how the distribution works under the covers so that I can better manage my system.
Not a problem...questions and answers are the entire reason to have mailing lists like this. Keep in mind that I'm quite possibly one of the least qualified people to speak on these subjects. I've been doing computer crudola for 45 years and I've seen a lot of stuff go flying by during that time. I am NOT currently a kernel developer, nor have I had anything to do with the design or implementation of any of the desktop environments. I'm a systems/network/storage architect and engineer with >20 years of programming experience to go along with it. To wit, I'm just a user--perhaps longer standing with more experience than many, but just a user. ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer, AllDigital ricks@alldigital.com - - AIM/Skype: therps2 ICQ: 226437340 Yahoo: origrps2 - - - ----------------------------------------------------------------------
-
Joe Zeff -
poma -
Rick Stevens -
Roger Heflin -
Stephen Morris -
Tom Horsley