- Arch-projects - lists.archlinux.org

Re: [arch-projects] [udev][RFC][2/5] moving static nodes to udev-compat
by Tom Gundersen 15 May '11

15 May '11

On Sun, May 15, 2011 at 12:31 AM, Aaron Griffin <aaronmgriffin(a)gmail.com> wrote: > I was under the impression that some of these nodes are needed for > udev to start working. At least, back in the day, I know that console, > null, and zero needed to be created before udev started. If this is no > longer true, then I see no issues with making them go away. Unless > they're needed in early userspace before udev starts... but mkinitcpio > could always create those nodes. They used to be needed. However, with devtmpfs they are not. The essential ones (for early userspace) exist by default and the rest are created when udev is started. A quick test: delete /lib/udev/devices from your machine and notice that everything still works. A more thorough test: move /lib/udev/devices to /lib/udev/devcise.old (say) and reboot with init=/bin/bash (it would be best to do this with a self-compiled kernel that can boot without a initramfs to make sure nothing touches /dev at all). Now compare the contents of /dev with /lib/udev/devices.old. Cheers, Tom

2 2

[arch-projects] [udev][RFC][5/5] remove custom rules to workaround old bugs
by Tom Gundersen 14 May '11

14 May '11

In 81-arch.rules we have a section that loads modules that cannot be auto detected. I think this is the wrong thing to do. If the kernel cannot auto detect it, then we probably are not going to be any better at it. Also, some of these rules might cause unwanted problems on systems that do not need the modules. E.g., the snd-{seq,pcm}-oss modules are known to cause problems with PulseAudio (and as PA is getting more and more common and OSS is getting more and more uncommon, I think it is clear that we are doing the wrong thing here). In general, I think all the modules of this section are exactly what rc.conf's MODULES array is for, so I suggest removing it. It might make sense to keep a wikipage dedicated to modules that cannot be autoloaded (cpufreq also comes to mind) and then add a note in udev.install pointing there. The relevant rules are below. Thoughts? Cheers, Tom ##################################### ###### Hotplug rules - begin # Only additional modules, # which are not detectable, # are loaded here! ##################################### # check if the device has already been claimed by a driver ACTION!="add", GOTO="drivers_end" # SOUND addon modules SUBSYSTEM=="sound", RUN+="/lib/udev/load-modules.sh snd-pcm-oss" SUBSYSTEM=="sound", RUN+="/lib/udev/load-modules.sh snd-seq-oss" #PNP addon modules SUBSYSTEM=="pnp", ENV{MODALIAS}!="?*", ATTRS{id}=="PNP0800", RUN+="/lib/udev/load-modules.sh pcspkr" SUBSYSTEM=="pnp", ENV{MODALIAS}!="?*", ATTRS{id}=="*PNP051[01]*", RUN+="/lib/udev/load-modules.sh irtty-sir" SUBSYSTEM=="pnp", ENV{MODALIAS}!="?*", ATTRS{id}=="PNPb02f", RUN+="/lib/udev/load-modules.sh analog" # PARPORT addon modules SUBSYSTEM=="pnp", ENV{MODALIAS}!="?*", ATTRS{id}=="PNP040*", RUN+="/lib/udev/load-modules.sh lp" SUBSYSTEM=="pnp", ENV{MODALIAS}!="?*", ATTRS{id}=="PNP040*", RUN+="/lib/udev/load-modules.sh ppdev" # fix ide cdrom detection on old proliant servers SUBSYSTEM=="pci", ENV{MODALIAS}=="pci:v00000E11d00000001sv00000000sd00000000bc06sc02i00", RUN+="/lib/udev/load-modules.sh ide-generic"

1 0

[arch-projects] [udev][RFC][4/5] removing module-load.sh
by Tom Gundersen 14 May '11

14 May '11

Hi guys, There has already been some discussion about this on the mailinglist, so I will just give a short summary here. At the moment, we have patches against initscripts that will create a blacklist file in /etc/modprobe.d/ (technically it is symlinked to a file on /run, but that is not important) at boot, based on the MODULES array in rc.conf. We still need to decide on exactly what to do with mkinitcpio that might want to have similar functionality. With this functionality added to initscripts it means that whatever modules were blacklisted in rc.conf at boot will not be autoloaded. This is the main functionality of modules-load.conf, and is as close to the intended upstream functionality we can get without breaking compatibility with rc.conf. Some functionality of load-modules.sh will be lost. However, I think it for the better (the closer we are to upstream the less weird bugs we will encounter). That said, if there are good reasons to implement any of these features I think it is doable. It should be noted that some of these things make a lot more sense in mkinitcpio than in initscripts, so if we drop these things from initscripts it does not mean we have to drop them from mkinitcpio. 1) You have to reboot between adding a module to rc.conf and it being blacklisted. If this is a problem for you, then use the method intended by upstream and add your blacklisted modules directly to /etc/modprobe.d/. I don't think we can avoid this problem. 2) MOD_AUTOLOAD will no longer work. This functionality is not upstream (correct me if I'm wrong!) and I find it hard to believe it is useful. As a boot parameter to fix a problem with the initrd it might be useful (though probably not in its current form, but that is another discussion), but I would like to remove it from rc.conf. If there is a use case for this, then we should follow whatever the other distros are doing and possibly help get this into udev.conf. 3) Can not blacklist modules on the kernel command line. Again, this is something that might be useful to get a working mkinitcpio so one can boot into a shell and fix one's system (if you know how to edit your grub command line then you should be able to set "init=/bin/bash"), but I don't think this is useful to blacklist modules from the real system. This _could_ easily be added, but I believe the correct place for this (if it is deemed useful) would be upstream. Thoughts? Cheers, Tom

1 0

[arch-projects] [udev][RFC][3/5] deprecate persistent-{net-cd}.rules
by Tom Gundersen 14 May '11

14 May '11

I'd like to remove the following deprecated functionality from initscripts/udev. The issue: If you have several networking devices or cd-rom's they might get their names swapped around on reboot. This is of course annoying. The old solution: udev ships with a rule file to automatically generate a persistent rule file in /etc every time it sees a new network device or cd-rom. The problems: /etc might not always be writable (in particular it is not during early boot when devices are typically probed), for this we have a workaround/hack in initscripts that will copy temporarily stored rule files to /etc when /etc becomes available. these days things like usb modems pretend to be cdroms so one might have potentially a lot of nonsense rules generated the functionality is basically deprecated upstream, i.e., they intend to rip it out as soon as someone has written a nice tool to replace it. For all intents and purposes it is dead. The correct solution: The user should not enable the auto generation rules, but rather create his/her own rules in the cases where they really want it. This is the same amount of manual intervention as enabling the rules, with none of the drawback. The correct procedure is excellently described here: <https://wiki.archlinux.org/index.php/Udev#Mixed_Up_Devices.2C_Sound.2FNetwo…> (the method referred to as the "udev-sanctioned" one). The situation in Arch: The auto generation rules are shipped, but patched to be disabled by default, the needed support is still in initscripts. My suggestion: We announce the deprecation and point users to the correct solution (maybe we fix up the relevant wiki pages a bit). After a not too long time we stop shipping the autogeneration rules, i.e., we pass --disable-rule_generator to configure in the udev package, and remove the support from initscripts. What this will mean for the end user: On an existing system where the rules are enabled and no new devices are added: nothing. On an existing system where the rules are enabled and a new device is added: the new devices will not get an auto generated persistent rule and an error will be logged. Thoughts? Cheers, Tom

1 0

[arch-projects] [udev][RFC][2/5] moving static nodes to udev-compat
by Tom Gundersen 14 May '11

14 May '11

In further simplifying our udev package I'd like to move all our static dev nodes (the contents of /lib/udev/devices) from udev to udev-compat. The reason for this is that it is not needed with a devtmpfs kernel, such as kernel26{,-lts}. In other words these static nodes are only useful for self-compiled kernels without devtmpfs support. The affected users are those who are using non-devtmpfs kernels without udev-compat, who should on the next upgrade install udev-compat. If we agree to do this I suggest an announcement to the news page in good time before the change and a note in udev.install. Thoughts? Cheers, Tom

1 0

[arch-projects] [udev][RFC][1/5] remove cdsymlinks.sh
by Tom Gundersen 14 May '11

14 May '11

The first thing I want to address is cdsymlinks.sh and the corresponding rules in 80-drivers.rules. As far as I understand the aim of this functionality is to create sensible symlinks to cdrom devices in /dev. Similar functionality is already provided by 60-cdrom_id.rules upstream, though it might differ slightly (from the git log, this rules file has had bugfixes that probably would apply to our rules too). I am inclined to simply remove our functionality and rely entirely on the upstream one. If there are use cases that we cover that upstream do not (I'm not aware of any), then I would be happy to take the lead on pushing the required patches upstream. This might cause some functional change to our users, but as far as I can tell a renamed cdrom symlink should not be the end of the world. Clearly, an announcement about this change must be made. >From what I have been told this was mostly relevant with the old standard fstab entries for cdroms. However, those have been removed a long time ago. Thoughts? Cheers, Tom

1 0

[arch-projects] [udev][RFC][0/5] moving udev closer to upstream
by Tom Gundersen 14 May '11

14 May '11

Hi guys, Tobias agreed to let me take over maintaining the udev package, and I have some ideas for changes I'd like to get everyone's comments on. Over the last few years udev has grown and distros have consolidated to the point where most distro's should be able to ship an unpatched version of udev. We are not as far away from upstream as we used to be, and we will still need to keep some patches due to backwards compatibility, but there is quite a lot we can get rid of. The aim is to simplify the maintainers job and benefit from all bug fixing happening upstream, this also means that we should file bug reports and push patches upstream rather than keeping our own rule files (to the extent it makes sense). Udev is very actively maintained with contributions coming from different distros, so this should be a benefit for everyone. In the five subsequent emails I'll outline the changes I'd like to implement. I cc'ed arch-dev-public on this email in case any interested parties are not on arch-projects, but I'll keep the rest of the discussion on arch-projects so we don't clog down peoples' inboxes :-) If anyone has any concern or suggestions pleas speak up :-) Cheers, Tom PS I just discovered that David Reisner is maintaining udev-vanilla in AUR which is almost exactly what I have in mind, so it might be worth checking out.

1 0

[arch-projects] [mkinitcpio] [GIT] The official mkinitcpio repository annotated tag 0.6.12 created. 0.6.12
by thomas＠archlinux.org 14 May '11

14 May '11

This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "The official mkinitcpio repository". The annotated tag, 0.6.12 has been created at 4d8772917e91a85422f1703840f0cf0ec776d8af (tag) tagging 121210bf369e15f66fcc831f2c7c212e1f3858bd (commit) replaces 0.6.11 tagged by Thomas Bächler on Sat May 14 13:25:18 2011 +0200 - Log ----------------------------------------------------------------- mkinitcpio 0.6.12 Gerardo Exequiel Pozzi (3): Drop deprecated /proc/sys/kernel/hotplug Trigger udev events like in initscripts Cleanly stop udev >= 168 as recommended by upstream. Thomas Bächler (2): Improve comments in mkinitcpio.conf Release mkinitcpio 0.6.12 Tom Gundersen (1): /run: restrict write access to root ----------------------------------------------------------------------- hooks/post-receive -- The official mkinitcpio repository

1 0

[arch-projects] [mkinitcpio] [GIT] The official mkinitcpio repository branch master updated. 0.6.11-6-g121210b
by thomas＠archlinux.org 14 May '11

14 May '11

This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "The official mkinitcpio repository". The branch, master has been updated via 121210bf369e15f66fcc831f2c7c212e1f3858bd (commit) via 60c9d0d292fbb8a54aaeec99037ef0d684897233 (commit) from df4bce44c5e21357043930e02acac23f104ea9b8 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- commit 121210bf369e15f66fcc831f2c7c212e1f3858bd Author: Thomas Bächler <thomas(a)archlinux.org> Date: Sat May 14 13:24:59 2011 +0200 Release mkinitcpio 0.6.12 commit 60c9d0d292fbb8a54aaeec99037ef0d684897233 Author: Gerardo Exequiel Pozzi <vmlinuz386(a)yahoo.com.ar> Date: Mon May 2 11:00:32 2011 -0300 Cleanly stop udev >= 168 as recommended by upstream. >From udev NEWS: The running udev daemon can now cleanly shut down with: udevadm control --exit Udev in initramfs should clean the state of the udev database with: udevadm info --cleanup-db which will remove all state left behind from events/rules in initramfs. If initramfs uses --cleanup-db and device-mapper/LVM, the rules in initramfs need to add OPTIONS+="db_persist" for all dm devices. This will prevent removal of the udev database for these devices. Signed-off-by: Gerardo Exequiel Pozzi <vmlinuz386(a)yahoo.com.ar> ----------------------------------------------------------------------- Summary of changes: Makefile | 2 +- init | 13 ++++--------- 2 files changed, 5 insertions(+), 10 deletions(-) hooks/post-receive -- The official mkinitcpio repository

1 0

[arch-projects] [mkinitcpio] [GIT] The official mkinitcpio repository branch master updated. 0.6.11-4-gdf4bce4
by thomas＠archlinux.org 14 May '11

14 May '11

This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "The official mkinitcpio repository". The branch, master has been updated via df4bce44c5e21357043930e02acac23f104ea9b8 (commit) from 34d985ae0ecdc18223ea7f42b9a4b2bfae657cc7 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- commit df4bce44c5e21357043930e02acac23f104ea9b8 Author: Tom Gundersen <teg(a)jklm.no> Date: Sun May 8 17:46:02 2011 +0200 /run: restrict write access to root This brings it in line with initscripts (and systemd), there should be no need for everyone to have write access to the /run folder. Reported-by: Pierre Schmitz <pierre(a)archlinux.de> Signed-off-by: Tom Gundersen <teg(a)jklm.no> ----------------------------------------------------------------------- Summary of changes: init | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) hooks/post-receive -- The official mkinitcpio repository

1 0