Small annoyances

Source

Not that it's anything new, but it would be really nice if someone would notice how useless this error message is: [adamw@adam SOURCES]$ sudo modprobe -r snd-ice1724 FATAL: Module snd_ice1724 is in use. [adamw@adam SOURCES]$ and fix it. Here is what it needs to look like: [adamw@adam SOURCES]$ sudo modprobe -r snd-ice1724 FATAL: Module snd_ice1724 is in use by PIDs 1234 and 4567 [adamw@adam SOURCES]$ as just telling me that it's 'in use' is about as useful as a sponge submarine when it comes to finding out what's using it...

Comments

eugeni wrote on 2011-05-26 00:56:
So very true... But personally, I think that the only way to fix such annoyances is by writing a custom module or module-init-tools wrapper to have them solved :(. Just like in http://xkcd.com/619/, The Core Developers are not human enough for such basic requests :).
misc wrote on 2011-05-26 08:08:
I am not sure it can be done. The module know who increased the usage count ( ie, another stuff in kernel-land usually it is a module, as you can see with lsmod ) when this is done by module loading. But it doesn't know anything about userland. Now, if we take the case of a sound card, there is some layer of isolationce on in the form of pulseaudio, alsa, etc. I listen to musc, it goes to pulseaudio, and later to alsa, and then to the sound card. Doing this would requires to carry a specific information trough all layer so the module can keep it, and if we want to be precise this should take in account that once a file is opened, the file descriptor could be passed to another process, thus adding some complexity to track change. So such system would requires to touch to several part of the kernel, as well as changing ABI and syscall of various part of the stack ( ie, when alsa open the card, we need to add some metainformation to give to the module ). That would be a huge change. And snce the kernel developpers were more in the mood of removing modules removal because it was complex to code, I doubt this gonna appear sound.