udev rules changes
bruce.dubbs at gmail.com
Sun Oct 28 20:29:40 PDT 2007
Bryan Kadzban wrote:
> Bruce Dubbs wrote:
>> 1. There is a doc directory that explains each rule file. Is there a
>> reason that we can't just incorporate these .txt files as comments in
>> the rules files themselves?
> The comments that cover our rules, we probably could. That wouldn't
> work for the Makefile's install-extra-doc targets though (since those
> try to document rules that come with udev).
> Also, I believe part of the purpose of these files was to give a user
> more of an overall picture (for instance, rather than explaining every
> rule, the former 25-lfs.txt (now 51-lfs.txt) file just explains each
> type of key used, and covers a few of the more complicated structures in
> the file). The idea was that this documentation would be a complement
> to writing_udev_rules.html.
> If that's still important (and I should look at the files again to make
> sure they still make sense with the deleted rules: I didn't read through
> all of them), I think having them in a separate set of files is helpful.
OK. I do prefer to have the documentation embedded in the rules files,
but it is only a mild preference.
>> 2. I would be in favor of changing the dialout group to tty which
>> would allow us to drop several rules.
> tty or uucp? The udev rules use uucp; if they used tty, I could likely
> have left them alone.
> If we want to add a new uucp group, we can kill 5-6 of the override
> rules, sure. :-)
Yeah. I sure don't like uucp. It is really an ancient reference. The
uucp rules do use it though for tty[A-Z]*|pppox*|ircomm*|noz*, mwave,
We do override tty[BCDEFHILMPRSTUVWX][0-9]* and ircomm[0-9]*, but not
the others. Perhaps we should add uucp just to catch the things we
don't override. We also don't handle TTYA[0-9]*. I don't know what
that would be. I only have ttyS on my system.
>> 3. I think the 51- rules should be renamed to 55- to allow users to
>> place their own rules between the udev default and ours without
>> modifying either.
> I don't have any real objection to that, but is there any case where a
> user would need to use those numbers?
> If they want to override something that's in both 50- and our file (i.e.
> we've already overridden it once), then whether our file is at 51- or
> 55- doesn't matter; they'll have to be after ours. If they want to
> override something that's in 50- but not our file, then it also doesn't
> matter whether we're at 51- or 55-: they can use any number after 50.
> And if they want to override a setting in our file that's not in 50-,
> then they'll still have to be after our file (whether we're at 51- or 55-).
> I can't come up with a reason that they'd have to add anything between
> the files, basically. Of course I may be missing something. :-)
It's not a big deal. I think it just gives the user flexibility. They
could override something in 50- that is also in ours by using the
>> 4. It states in the book that continuation of rules are not allowed
>> with a backslash-newline combination. In udev-116's
>> udev_rules_parse.c, it looks like backslashes are recognized. The
>> function is parse_file and starts at line 657 of the file. Checking
>> git, it appears that this has been available since 20 Dec 2004:
>> This was released in udev-051.
> Oh really. I think that text has been in the book for a fairly long
> time (though perhaps not in the place it is now), but it's entirely
> possible that it's out of date with current udev. I'd agree that
> current udev_rules_parse.c looks like it'll handle continuation
> characters just fine; let me test it a second...
> Yeah, udev-110 works with backslash-newline continuation, so the book
> should be changed (assuming -116 works as well, but I don't think they'd
> remove that). :-)
>> If continuation lines are indeed allowed, I think we can make our
>> rules with long lines look better with this feature. We would also
>> need to change the book.
> Yes, I'd agree. I may be able to look into it tomorrow, but if you
> already have a patch put together for these, don't wait for me. ;-)
No, I don't have anything ready to go. I wanted to discuss it first. I
do not see a big need to hurry on this, but we ought to make the changes
while we are thinking about it.
More information about the lfs-dev