SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
now maybe i was not supposed to do that, but it worked.
under 14.1, when i run udevadm test on the rule it tells me "kernel device nodes cannot be renamed". in the udev manual it says the name of a device node cannot be changed by udev. ok.
but what if the node did not exist prior to execution of the rule?
was i doing it wrong back under 13.37?
You can't rename a device node, but you can create a symlink instead. The rule will only be processed when all the matching attributes from the device are present.
my confusion is if there is a difference between rename and create. in 13.37 i was able to create new nodes and symlinks. with 14.1 i can't create or rename, only symlink. it plainly says you can't rename a node, but there is no mention of not being allowed to create a new node.
i seem to have found the answer to my own question.
from what i can find, back during slackware 13.37 and ubuntu 12.04,
udev could handle the NAME= option. but later on when udev merged
with systemd and incorporated with devtmpfs, this "feature" was
removed.
according to kay sievers, an application should either enumerate on
its own based on properties found or make use of symlinks.
i wish i understood the reasoning behind this decision, but i guess
it is what it is.
i wish i understood the reasoning behind this decision, but i guess
it is what it is.
It's been a done deal for several years now, and it did bring rigorous changes like this. This udev wiki page mentions...
Quote:
In April 2012, udev's codebase was merged into the systemd source tree, making systemd 183 the first version to include udev.[6][12][13] In October 2012, Linus Torvalds criticized Kay Sievers's approach to udev maintenance and bug fixing related to firmware loading, stating:[14]
Yes, doing it in the kernel is "more robust". But don't play games, and stop the lying. It's more robust because we have maintainers that care, and because we know that regressions are not something we can play fast and loose with. If something breaks, and we don't know what the right fix for that breakage is, we revert the thing that broke. So yes, we're clearly better off doing it in the kernel. Not because firmware loading cannot be done in user space. But simply because udev maintenance since Greg gave it up has gone downhill.
i seem to have found the answer to my own question.
from what i can find, back during slackware 13.37 and ubuntu 12.04,
udev could handle the NAME= option. but later on when udev merged
with systemd and incorporated with devtmpfs, this "feature" was
removed.
according to kay sievers, an application should either enumerate on
its own based on properties found or make use of symlinks.
i wish i understood the reasoning behind this decision, but i guess
it is what it is.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.