3 ms·

Driver issues, right.. is that why my archived shell histories have hundreds if not thousands of entries for `pulseaudio --kill ; puslseaudio --start` ? Does

Driver issues, right.. is that why my archived shell histories have hundreds if not thousands of entries for `pulseaudio --kill ; puslseaudio --start` ? Does restarting the userland sound daemon reset the drivers operating in kernel space? How would that work?

mixedCase 4y ago
Have never used those APIs, but I would assume it'd happen if drivers fail to implement basic API promises and PulseAudio doesn't code defensively against those kind of bugs.
- vintermann 4y ago
  If drivers fail that disastrously to implement the APIs they say they implement, how did they end up in distributors' kernel trees?
  - ElectricalUnion 4y ago
    They were deemed "good enough" when all you were using was basic, simple OSS. Not when you're attempting to use all the capabilities of ALSA.
- robonerd 4y ago
  > PulseAudio doesn't code defensively against those kind of bugs. That's a reoccurring pattern across Lennart software. He gets an idea of the way things should work, maybe from the spec or maybe just from his own subjective biases, and has his software expect things to work that way and fail when it doesn't. Every time, he'll say it's the other guys fault. Sometimes his software even fails unsafe and he still blames everybody else. The '0day' username bug in systemd exemplifies this. Lennart decided that usernames beginning with numbers weren't valid, even though Linux permits it. Systemd was found to run service files with User=0day specified as root instead, not as the user 0day. To Lennart this was not a bug because in his subjective opinion the rest of the system was in error for permitting a username beginning with a number. Even if he were right that usernames beginning with numbers shouldn't be valid, the mere fact that they can occur is reason enough to code defensively around it. At the very least systemd could fail safe when it encounters such an 'invalid' username. But no, he thought there was nothing wrong with failing-to-root. It was everybody else's fault, of course. https://lwn.net/Articles/727490/ https://lwn.net/Articles/727490/ https://github.com/systemd/systemd/issues/6237#issuecomment-311900864 https://github.com/systemd/systemd/issues/6237#issuecomment-...
ElectricalUnion 4y ago
Driver issues can sometimes manifest as kernel exposed API interfaces blocking/using too much CPU in stupid ways/freezing when they should not; killing the "offending" userland program using those APIs will often end up releasing the resources acquired by invoking them. Linux might be a monolithic kernel, but it's not like the entire kernel with all it's features/modules need to be loaded all at once.

mixedCase 4y ago

Have never used those APIs, but I would assume it'd happen if drivers fail to implement basic API promises and PulseAudio doesn't code defensively against those kind of bugs.

vintermann 4y ago
If drivers fail that disastrously to implement the APIs they say they implement, how did they end up in distributors' kernel trees?
- ElectricalUnion 4y ago
  They were deemed "good enough" when all you were using was basic, simple OSS. Not when you're attempting to use all the capabilities of ALSA.
robonerd 4y ago
> PulseAudio doesn't code defensively against those kind of bugs. That's a reoccurring pattern across Lennart software. He gets an idea of the way things should work, maybe from the spec or maybe just from his own subjective biases, and has his software expect things to work that way and fail when it doesn't. Every time, he'll say it's the other guys fault. Sometimes his software even fails unsafe and he still blames everybody else. The '0day' username bug in systemd exemplifies this. Lennart decided that usernames beginning with numbers weren't valid, even though Linux permits it. Systemd was found to run service files with User=0day specified as root instead, not as the user 0day. To Lennart this was not a bug because in his subjective opinion the rest of the system was in error for permitting a username beginning with a number. Even if he were right that usernames beginning with numbers shouldn't be valid, the mere fact that they can occur is reason enough to code defensively around it. At the very least systemd could fail safe when it encounters such an 'invalid' username. But no, he thought there was nothing wrong with failing-to-root. It was everybody else's fault, of course. https://lwn.net/Articles/727490/ https://lwn.net/Articles/727490/ https://github.com/systemd/systemd/issues/6237#issuecomment-311900864 https://github.com/systemd/systemd/issues/6237#issuecomment-...

ElectricalUnion 4y ago

Driver issues can sometimes manifest as kernel exposed API interfaces blocking/using too much CPU in stupid ways/freezing when they should not; killing the "offending" userland program using those APIs will often end up releasing the resources acquired by invoking them. Linux might be a monolithic kernel, but it's not like the entire kernel with all it's features/modules need to be loaded all at once.