Hi Nicolas, Am 05.04.19 um 13:34 schrieb Nicolas Saenz Julienne: > Hi, > this series tries to address an issue that came up in Raspbian's kernel > tree [1]. After pulling from upstream some changes that moved wait calls > from a custom implementation to the more standard killable family some > users complained that all the VCHIQ threads showed up in D state (which > is the expected behaviour). this issue has already been noticed in mainline distributions [1],[2]. > The custom implementation we deleted tried to mimic the killable family > of functions, yet accepted more signals than the later. SIGKILL | > SIGINT | SIGQUIT | SIGTRAP | SIGSTOP | SIGCONT for the custom > implementation as opposed to plain old SIGKILL. > > Raspbian maintainers decided roll back some of those changes and leave > the wait functions as interruptible. Hence creating some divergence > between both trees. > > One could argue that not liking having the threads stuck in D state is > not really a software issue. It's more a cosmetic thing that can scare > people when they look at "uptime". On the other hand, if we are ever to > unstage this driver, we'd really need a proper justification for using > the killable family of functions. Which I think it's not really clear at > the moment. I like to see this decision as a short comment in the code to prevent other for doing this mistake again. Thanks Stefan > > As Raspbian's kernel has been working for a while with interruptible > waits I propose we follow through. If needed we can always go back to > killable. But at least we'll have a proper understanding on the actual > needs. In the end the driver is in staging, and the potential for errors > small. > > Regards, > Nicolas > > [1] https://github.com/raspberrypi/linux/issues/2881 > [1] - https://archlinuxarm.org/forum/viewtopic.php?f=65&t=13485 [2] - https://lists.fedoraproject.org/archives/list/arm@xxxxxxxxxxxxxxxxxxxxxxx/message/GBXGJ7DOV5CQQXFPOZCXTRD6W4BEPT4Q/ _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
