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 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
