udev rules use old-style operators

[Matthew Burgess]

From udev-055, udev supports '=', '==', '!=,' , '+=' operators. The RELEASE-NOTES for that version states: "The current simple '=' is still supported, and should work as it does today, but existing rules should be converted if possible, to be better readable."

Looks like we dropped the ball on this one, as 6.1 went out with udev-056 but the rules file used the old-style '=' operator. If anyone wonders how I realised this, it got brought up in ​http://www.ussg.iu.edu/hypermail/linux/kernel/0508.2/0236.html.

[steve.crosby@…]

We actually need to completely revamp our rules - the udev.rules that used to be provided is now gone, so we need to make sure our LFS rules include the functionality that was previously in that default reule set. Probably the Gentoo rules in the distro subdir of udev tarball are closest to what we want.

Ideally we should make our own and submit to upstream for inclusion in the udev package, but that involves lots of work deciphering the new ruleset ;)

[Matthew Burgess]

I don't understand your reasoning behind the first paragraph at all, Steve. We never installed the default rulesets previously, as far as I know, so we haven't lost any functionality surely?

As far as submitting our rules upstream goes, I'm not sure that fits in with "LFS is not a distro"/"Your distro, your rules" philosophy.

I do, however, agree that the rules need revamping. We need to agree on a set of rules that a) match the work being done in bug 1032 b) match current upstream recommendations for rule syntax and c) are consistent on handling (or not!) devices that only work with packages outside of LFS. The last one is potentially contentious!

[ken@…]

I guess Steve means 50-udev.rules has gone.

I think we can take this "not a distro" approach too far - clearly, we aren't

going to take out our bootscripts and replace they by a "now you need to write some bootscripts" page ;) It's not my call, and needs discussion if people think it's the way to go, but I can see benefits in replacing our patch with something in the upstream package.

I haven't had time to look at 067 yet, or even to see if 25-lfs.rules includes everything in the old 50-udev.rules, so apologies if I've yet again misunderstood.

[Matthew Burgess]

Thanks Ken, and apologies to Steve! So, yes, I'm in agreement...partially. We need to ascertain what devices we were providing with the combination of 25-lfs.rules and 50-udev.rules, and whether those devices are within whatever bounds/policies we want to employ. Whether or not to then submit the resultant rules upstream we can decide on at a later date.

[Matthew Burgess]

Steve, the udev.rules file is really short, so a visual inspection verified that the only thing we don't handle in our 25-rules file is:

# emulate dev.d/ RUN="/sbin/udev_run_devd

In actual fact, 25-rules.dev is slightly better than the default rules, as it changes group ownership on a couple of devices too.

What we need to do now, is do a thorough comparison of all the example rules provided by udev and the ones we currently install, to see what the general consensus seems to be on typical naming and ownership conventions. Then, if we deem some devices to be unsuitable for/unusable with a stock LFS install, we can remove them.

[ken@…]

QA question :

we have kernel="js*" and a little later kernel="js" - doesn't the first of these include "js" ?

What do you plan on doing with the unsuitable/unusable rules ? I'm thinking

they've already been created in a sensible fashion, and some day somebody will put LFS on that kit (e.g. we've got dasd in there, and a few months back somebody was doing LFS on zSeries, but 99.9% of users won't have that sort of hardware).

[Matthew Burgess]

Regarding "js*" vs. "js", I don't know. I'd guess it depends on how udev treats the '*' - if it's a "1 or more characters" it won't match "js", it's a "zero or more characters" it will.

As for your second comment, I'm again torn between these two arguments:

1) Let's put every conceivable device in our rules file, with sane names and ownership. Rationale: LFS creates the /dev directory and handles its population via udev, therefore it should ensure devices get created sensibly inside it. 2) Let's put whatever devices don't require packages outside of LFS in /dev. Rationale: You can't use the device without going BLFS, therefore LFS shouldn't care how that device gets created.

Maybe this needs to go to lfs-dev at this point?

[Matthew Burgess]

I've uploaded a listing of my /dev directory using each of the rule configurations provided in udev-068 and LFS' rules. See ​http://www.linuxfromscratch.org/~matthew/udev-results/. I've just noticed that the results may not be entirely accurate, as the cdrom symlink is handled by cdromid in some of the rules, and we don't install that at the moment. Obviously, any other rules that call out to the helper binaries will cause differences too.

[b3nt@…]

sed -i 's@L="@L=="@g' udev-config-3.rules sed -i 's@S="@S=="@g' udev-config-3.rules

[Matthew Burgess]

I'm marking this as FIXED, following r7026 (trunk) and r7027 (6.1.1). The initial bug concerned the use of old-style operators, which have now been converted in the updated rules file. We're obviously aware of the other issues with the Udev rules, and they'll be dealt with as part of the wider ranging udev/hotplug changes.