udev rules changes

Bruce Dubbs 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,
and hvc*|hvsi*.

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[01234567] 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
OPTIONS="last_rule" construct.

>> 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:
>> http://git.kernel.org/?p=linux/hotplug/udev.git;a=commit;h=9f8dfa19cfd2b502bf794f39a421cbb7c4cc0404
>> 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.

  -- Bruce

More information about the lfs-dev mailing list