On Sun, 27 Aug 2017 at 19:23:11 -0400 Hendrik Boom <hend...@topoi.pooq.com> wrote:
> On Sun, Aug 27, 2017 at 12:05:56AM +0200, Alessandro Selli wrote: >> >> This idea does has some merit, but it cannot always prevent the >> necessity to reconfigure a system's networking due to a hardware change >> and to a sysadmin's specific needs; sometimes a cars with NIC >> 0b:45:81:f4:3e:01 is to be en1, sometimes a never-before-seen card needs >> to be given the same name. How is the system supposed to know? It >> cannot, the sysadmin will still need to adjust thing by hand according to >> what it's needed in the specific circumstances. I'd like a system that >> was as simple as possible to configure and maintain that made this >> renaming as straightforward as possible, not as complicated ad udev rules >> are. > > Do I understand you ccorrectly: that the udev rules are flexible > enough to do the right thing, but they are too hard to use? Yes. On some occations I had to find out where in /sys a device had it's control and attribute directory (not easy at all to a newbie) and then run a command such as: # udevadm info --attribute-walk /sys/devices/pci0000\:00/0000\:00\:1a.0/usb1/ to get a long list of attributes to select from when building my own rule that isolated a single device. And I remember in a few occasions my old rules stopped working and I had to redo them to reflect a change in rules syntax that was introduced from a udev's version onwards. And I could not have udev run a command at device hot-plug. Too cumbersome and little intuitive. And not well documented, at least at the time (a few years ago). Alessandro _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
