On Sun, Jul 21, 2013 at 8:32 AM, Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
>
> Given that udev also fixed the issue in newer versions, if someone is
> wanting to run an older kernel with an updated udev, I would think they
> would update to a newer version without this issue.
What reality-distortion field does Kay have around you that you make
that statement?
udev never fixed the problem as far as I know. Certainly not before
the kernel change, and after the kernel change Kay stepped up and
asked that we do it entirely in the kernel and not bother udev at all.
And *before* that, Kay spent four months *denying* it was a udev
problem at all, pointing fingers elsewhere. Seriously. He first said
that the problem doesn't exist - because network drivers should load
their firmware at ifconfig time, not module load time. While that is
actually very true for many of them, it's irrelevant, since this
primarily hit drivers like the v4l media drivers (a few bad network
drivers were hit too). When that failed, he then went on to talk about
how "nothing broke", it was just a bit slow (30-second lockups at
boot? "not broken"? Most people probably never sent a bug-report, they
probably assumed the boot was broken and gave up long before).
He then stated quite clearly that he would *not* fix it, since it was
against some fundamental design of his. The very kernel mailing list
thread Francis quotes is from the fact that Kay had tried to convince
Mauro and the media people that there was a need for a new "async
probe" for this issue, despite that being (a) fundamentally broken and
(b) requiring all affected drivers to be totally re-done for probing.
Why? Because Kay had made a change to udev that made *everything*
synchronous, and broke how it had always just done async firmware
loading on its own.
Greg, there's a reason we do firmware loading in the kernel. It wasn't
because there was one or two buggy udev releases. It was because the
udev maintainer knowingly broke it, argued for his breakage for a long
time, and ACTIVELY REFUSED TO FIX IT.
There were even patches sent to the systemd mailing list to fix it,
and Kay refused to apply them. They were not complicated patches. They
were literally one-liners saying "if it's a firmware load event, just
do it immediately without serializing against other things, because
the things you may be serializing against may be the thing that wants
to load firmware!".
This went on for several months - Kay had actively closed udev
bugzilla entries due to blaming other things. There was never a udev
fix. By the time I stepped in, it was already an old issue because of
all the dancing around that Kay had done, blaming anything but
himself.
Seriously, Greg, you seem to have this huge blind spot when it comes
to udev problems. You post denigrating posts on G+ about the forks,
and something makes you have this very selective memory of what
actually happens.
Linus
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html