https://bugzilla.novell.com/show_bug.cgi?id=673845
https://bugzilla.novell.com/show_bug.cgi?id=673845#c102
--- Comment #102 from Jeff Mahoney
Jeff: you joined this bug too late. See comment #45 on why we have a separate package... :-)
Indeed. There's a big mess to clean up here. The printer modules have *always* been loaded when the device file was accessed. This hasn't changed. There is no regression in the kernel here. This is how module autoloading worked in the "old days" for nearly everything and that's changed now that we have sane device discovery. This was from the days of a mostly static /dev. In order for lp.ko to be accessed /dev/lp* needs to be opened first. The module will then be loaded automatically. The only other way to do this is to load the module manually, after which udev will create the device files. The first option is the only one that works automatically. Udev is now responsible for creating the device nodes. This is true in either of the debated solutions. It will create them by reading the MODULE_ALIAS attributes and it will create them by copying the files from /lib/udev/devices. In either case, udev is responsible for creating the nodes. The reason I'm pushing for the /lib/udev/devices option is because it's simple. It's a packaging change and one that Fedora has already demonstrated to be working. The MODULE_ALIAS solution will, quite simply, *never* be accepted upstream. It's also a code change for a problem that can be fixed by adding several lines to the spec file. So that makes the choice between maintaining a patch to our kernel, outside of mainline, forever or adding a few lines to a spec file to create the nodes. I think the preference is obvious. Now, to answer Johannes' question: (In reply to comment #101)
I have a question:
What happens if a RPM package contains the udev files --------------------------------------------------------------- crw-r--r-- 1 root lp 6, 0 ... /lib/udev/devices/lp0 crw-r--r-- 1 root lp 6, 0 ... /lib/udev/devices/lp1 crw-r--r-- 1 root lp 6, 0 ... /lib/udev/devices/lp2 crw-r--r-- 1 root lp 6, 0 ... /lib/udev/devices/lp3 ---------------------------------------------------------------
Thanks for pasting this chunk. This is actually a bug in my submission. They should be: crw-r--r-- 1 root lp 6, 0 ... /lib/udev/devices/lp0 crw-r--r-- 1 root lp 6, 1 ... /lib/udev/devices/lp1 crw-r--r-- 1 root lp 6, 2 ... /lib/udev/devices/lp2 crw-r--r-- 1 root lp 6, 3 ... /lib/udev/devices/lp3
but on the computer where those RPM package is installed there is no parallel port hardware at all?
The device files are created but accessing them returns -ENODEV or -ENXIO.
Could this cause any kind of errors or udev warning messages when udev tries to create the device nodes even when there is no parallel port hardware?
No. You could populate that directory with random device nodes and udev wouldn't complain.
Could this cause any kind of subsequent problems?
No. Your example isn't a problem.
E.g. might /dev/lp0 /dev/lp1 /dev/lp2 /dev/lp3 exist even on a computer without parallel port hardware?
Yes. But that's the point of all of this. lp can't be automatically detected. It can only be loaded automatically when the device is accessed and to access the device, the device nodes must exist. This is, unfortunately, how legacy devices work. So, in order for parallel printing to work, those device nodes *must* exist. Having them in a separate package is only a good idea if the point of the package's existence is to be Required by multiple printing systems. If we only care about cups, the device nodes should be pulled into the cups package like they are on Fedora. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.