Version: (using KDE 4.0.5) OS: Linux Installed from: Compiled From Sources Replacing hardware on a Linux machine can have some nasty side effects. UDEV tries to assign unique names to unique pieces of hardware. This is nice, but it leads to some confusing effects when the user replaces hardware components, line an ethernet card or a DVD drive. When, for example, an ethernet card is replaced, UDEV will be unable to detect the old card, which has been assigned the name 'eth0'. At the same time, UDEV detects a new card and assigns it the name 'eth1'. The same happens when a DVD drive is replaced. The device 'dvd' will not function anymore, and a new device 'dvd1' will be created. The above leads to problems on the software level. Software that was configured to address the 'eth0' or 'dvd' device will not work anymore. The user might think that the new hardware is broken. It would be of great help to the user when Solid could offer some help. I would like to suggest the following solution: * User replaces hardware and boots the computer * Solid detects a possible hardware replace (old device gone, new device emerged) * Solid asks user if the new device should replace the old one or not. * When user asks Solid to replace, Solid should change the UDEV rules in order to make the new device actually work as a replacement of the old one.
The suggestion as written sounds dangerous. As you said, one of the design goals of UDEV was to have persistant, unique naming for each piece of hardware. Making UDEV behave in a way different than what its documentation and design say it should can have unforeseen consequences and could cause problems down the road. The real problem is in other apps directly reference specific hardware devices. KDE should not be changing settings other subsystems (HAL, UDEV) to fix non-KDE apps designed in this manner. In the same token, KDE apps should be designed to gracefully handle such hardware changes. A better solution to clobbering UDEV configuration files would be to have Solid know what the device is supposed to do, and simply choose the most appropriate, currently-present hardware to pass to the application. I was under the impression that this is a design goal of Solid. There's already a network management backend that talks to NetworkManager on Linux. So rather than having Solid change the UDEV rules to make the new device work as a replacement of the old one, it should change *its* rules so that applications using Solid will Just Work (TM). To me, it seems like the Right Solution is to not step on the toes of other subsystems, but work with them to make the user experience smooth. Apps that still directly talk to hardware *should* suffer your described problem - it's a side effect of the assumptions the application author made, and should be fixed by that application's developer, not hidden by a change made by an unrelated project here. Further discussion should probably move to a mailinglist.
A completely agree on your remark about the design gloal of UDEV. Having persistent device names usually is a blessing, provided by UDEV. However, persistent device names are not always what the user wants. UDEV has no means to interact with the user and solve hardware issues interactively. So, UDEV is doing the right thing and it cannot solve this problem. The desktop environment (KDE in this case) can. You say we should not step on the toes of other subsystems, but work with them to make the user experience smooth. As I see it, KDE currently does *not* work with them and therefore does *not* make the user experience smooth (I'm talking about the specific problem of replacing hardware here). Currently I, the user, have to go in and manually remove UDEV rules from config files when I replace my DVD drive. That's not smooth. I'd rather see KDE clobbering config files (after asking the user) than to force users to start clobbering around. Solid can make UDEV work with the user and make the experience smooth. I agree that the issue can be solved in a more elegant way when applications do not use device names like '/dev/cdrom1' directly. They should ask Solid to provide them with one. But... This solution works for KDE applications only. Even if GNOME would adopt Solid, it would not solve the problem of device names. There's more than just KDE and GNOME applications. It's OK with me to discuss this on a mailing list. Which one?
You do make some good points, particularly about having Solid do the edits rather than force the end user to tinker with global conf files himself... kde-hardware-devel@kde.org seems most appropriate. If you'll start off with a new thread (maybe even just copy-paste your original wish/explanation?), I'll be more than happy to discuss further. Thanks! :)