Udev hierarchy for rules

KimTjik · 2011-06-24 14:42:22

I've been searching and reading a lot of documentation, but cannot find any specific layout for udev hierarchy. What I refer to is prefix numbers. Can anyone provide a link or simple explanation?

Before I add anything to the Wiki I would like to get confirmed information about prefix numbers. I've already seen so many suggestions about udev rules, fairly similar, but all with different numbers, that I hesitate to add yet another. Probably it's not crucial. Still a system make maintenance easier.

rwd · 2011-06-24 16:58:26

You mean the filename prefix of the .rules files? AFAIK their only significance is that the files are evaluated in the order of with lowest prefix to highest.

KimTjik · 2011-06-24 17:36:33

rwd wrote:

You mean the filename prefix of the .rules files? AFAIK their only significance is that the files are evaluated in the order of with lowest prefix to highest.

Yes, that exactly what I mean. Could be you're right. I just wanted to ask and see if anyone has seen any suggestions about it. Maybe I'm only looking for an order that's not there.

falconindy · 2011-06-24 20:19:55

udev rules exist in a global namespace, so order of processing is important. Rules files are processed in lexicographical order on a per directory basis (/lib/udev/rules.d followed by /etc/udev/rules.d) -- the prefixes only serve to allow userspace to enforce this ordering. And yes, the .rules suffix is necessary in order for the file to be recognized.

Last edited by falconindy (2011-06-25 12:51:22)

KimTjik · 2011-06-24 21:44:30

Is there any recommended order by category, or none is set?

As I understand your comments, it's up to me, as a user, to decide a number according to when in the chain I want it to come (/etc/udev/rules.d/).

rwd · 2011-06-24 23:44:34

I don't understand what categories you refer to. As the udev manpage and wiki states, when a device is added/removed the rules are simply evaluated in lexical order, and if a rule matches the device some action is performed. It is not a chain in the sense that one is depending on the other.

Last edited by rwd (2011-06-24 23:54:00)

KimTjik · 2011-06-25 09:45:26

Sorry for using a wrong term, chain, because that wasn't what I meant. My bad.

What I was thinking about was if series 10 and 20 and so on preferably should be used for a category of rules. Why I ask is because I already see suggestions about writing rule X as being 99-.rules or 34-.rules or 82-.rules. I understand that in practise it doesn't make a difference, unless there's a conflict between rules. I suspected there isn't any clear recommendation but I choose to ask nevertheless.

If there's no system for categorizing rules I suppose our Wiki could be adjusted as to not indicate such an order. Because that's why I suspect suggestions about 11- that or 82- that spread around the web, as if the number has significance. It becomes a copy and paste "mess".

Maybe I'm too systematic in my thinking here, but that's the way my mind work. I always look for patterns and maths even though it doesn't matter much.

falconindy · 2011-06-25 13:03:31

Source code -- the ultimate documentation. Sorry, I'm about to reveal all of udev's magical secrets (not really).

if (udev_get_rules_path(udev) == NULL) { 
  char filename[UTIL_PATH_SIZE];

  /* /lib/udev -- default/package rules */
  add_matching_files(udev, &file_list, LIBEXECDIR "/rules.d", ".rules");

  /* /etc/udev -- system-specific/user/admin rules */
  add_matching_files(udev, &file_list, SYSCONFDIR "/udev/rules.d", ".rules");

  /* /run/udev -- throw-away/temporary rules */
  util_strscpyl(filename, sizeof(filename), udev_get_run_path(udev), "/rules.d", NULL);
  add_matching_files(udev, &file_list, filename, ".rules");
} else { 
  /* custom rules files location for testing */
  add_matching_files(udev, &file_list, udev_get_rules_path(udev), ".rules");
}

/lib/udev/rules.d, /etc/udev/rules.d, and then /run/udev/rules.d (a recent addition), are parsed in order -- any file with a .files suffix for the first two and any file at all in /run/udev/rules.d is assumed to be a valid rules file.

So how does add_matching_files work... Well, it's basically just a readdir loop over the contents of each directory above, with the final key line:

udev_list_entry_add(udev, file_list, dent->d_name, filename, UDEV_LIST_UNIQUE|UDEV_LIST_SORT);

The 'unique' and 'sort' bits have interesting implications:
- unique implies that directories which are parsed later can override a rules file by declaring it with the same name. That is, given /lib/udev/rules.d/10-foo.rules and /etc/udev/rules.d/10-foo.rules, the rule in /etc will prevail and completely override anything done in the rule in /lib. This occurs in libudev/libudev-list.c if you want to see it for yourself.
- sort implies that rule precedence is on a global scale. /run/udev/rules.d/1-foo.rules will always be processed before /lib/udev/rules.d/10-foo.rules, even though /run/udev is parsed "last".

rwd · 2011-06-25 13:19:25

falconindy wrote:

Source code -- the ultimate documentation...

Interesting, thanks. Still source code shows how something works, not necessarily how it is designed to work, or specified to work.;)

Arch Linux

#1 2011-06-24 14:42:22

Udev hierarchy for rules

#2 2011-06-24 16:58:26

Re: Udev hierarchy for rules

#3 2011-06-24 17:36:33

Re: Udev hierarchy for rules

#4 2011-06-24 20:19:55

Re: Udev hierarchy for rules

#5 2011-06-24 21:44:30

Re: Udev hierarchy for rules

#6 2011-06-24 23:44:34

Re: Udev hierarchy for rules

#7 2011-06-25 09:45:26

Re: Udev hierarchy for rules

#8 2011-06-25 13:03:31

Re: Udev hierarchy for rules

#9 2011-06-25 13:19:25

Re: Udev hierarchy for rules

Board footer