<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_RESOLVED bz_closed" title="RESOLVED WONTFIX - xf86-video-nouveau fails to modprobe nouveau: KMS not enabled" href="https://bugs.freedesktop.org/show_bug.cgi?id=60772#c14">Comment # 14</a> on <a class="bz_bug_link bz_status_RESOLVED bz_closed" title="RESOLVED WONTFIX - xf86-video-nouveau fails to modprobe nouveau: KMS not enabled" href="https://bugs.freedesktop.org/show_bug.cgi?id=60772">bug 60772</a> from <a class="email" href="mailto:hkmaly@bigfoot.com" title="Honza <hkmaly@bigfoot.com>"> Honza</a> <pre>(In reply to <a href="show_bug.cgi?id=60772#c13">comment #13</a>) > (In reply to <a href="show_bug.cgi?id=60772#c11">comment #11</a>) > > Mirkin: You might've overlooked it, but there IS patch in the message you > > posted reference to. I don't see what other patch might be needed. > > > No-one is saying there is a need for (other) patch(es) > "If you really want to change the behaviour, send a patch, ping people, etc." > > I fail to see why you think it's necessary to change behaviour of > > xf86-video-nouveau to support less workflows just to force the workflow you > > prefer. All replies against this patch I saw was on ideological ground, none > > presented any real reason why it's better this way. > > > Afaics thing will work fine if you use udev/eudev/mdev over linux-hotplug. > In the latter of which I cannot see any progress (or changes) over the last > few years. > I successfully ignored devfs. Fads like that come and go. No need to change what's working. Current attempts of integrating pulseaudio and init doesn't convince me udev is stable. Sure, sysvinit didn't have much change in last few years ... because it's working. Systemd, on the other hand ... > Whereas for the ideological ground - I think that the maintainer of the > kernel drm subsystem(Dave) would know better. Yes a bit more information > would not hurt, but considering the other drivers are doing this I do not > see it as a wrong thing/bikeshedding. > > Btw, I believe he already mentioned that it's racy :) > He mentioned that there is race when you start the module and X server immediately starts using it. If you start udev and immediately after it start X, the race will still be there, wouldn't it? In fact, it will be even worse, as udev doesn't exactly have predictable timing. With distributions trying to make startup fast and parallel and often starting display managers-based logins, I'm actually surprised it works. If the code would be supposed to solve the race, it would contain cycle sleeping until some ioctl returns the module finished initialization. Probably with timeout around 30 seconds.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>