From: Kay Sievers <kay@vrfy.org>
To: Tom Gundersen <teg@jklm.no>
Cc: Maarten Lankhorst <m.b.lankhorst@gmail.com>,
Linux Wireless List <linux-wireless@vger.kernel.org>,
Andy Lutomirski <luto@amacapital.net>,
Intel Linux Wireless <ilw@linux.intel.com>,
Johannes Berg <johannes@sipsolutions.net>,
linux-hotplug@vger.kernel.org,
Bryan Kadzban <bryan@kadzban.is-a-geek.net>,
systemd Mailing List <systemd-devel@lists.freedesktop.org>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] udev: fail firmware loading immediately if no search path is defined
Date: Sat, 10 Aug 2013 21:28:18 +0000 [thread overview]
Message-ID: <CAPXgP11LnVqTxsKUoLTLwtP-oxcekkNxmPG2X-R+2U9S4-dAgQ@mail.gmail.com> (raw)
In-Reply-To: <CAG-2HqUT3hbFPSEqYnJvBOgS6p4dKf=nhqZtzqS-on8FFe9ipA@mail.gmail.com>
On Sat, Aug 10, 2013 at 11:00 PM, Tom Gundersen <teg@jklm.no> wrote:
> It would be simple enough to add an udev rule to just print 'ignoring
> firmware event' to the logs.
This and I guess:
SUBSYSTEM="firmware", ACTION="add", ATTR{loading}="-1"
would also just cancel the request at the same time without any other
code needed.
The udev firmware support just a configure option, just like the
kernel has them. So distributions should enable it in udev and the
kernel if they need it.
We simply cannot coordinate the defaults of systemd and the kernel
because the rules of the kernel are different. The kernel does "keep
defaults like stuff has been in the past" and udev does "make default
what makes the most sense on current systems".
> We should really ignore the event though, and
> not cancel it. Not sure if this is something we want upstream (after all,
> there are plenty of situations where we don't warn if the recommendations in
> the README file are not followed), or if distros and whoever wants it should
> ship that themselves. I'll leave that for Kay to decide.
The proper fix is that userspace firmware should be disabled in the
kernel for new systems, and kept enabled only for old systems. Old
systems need to enable a new udev version to support firmware loading.
There are currently broken in-kernel mis-users of the firmware
interface that use the firmware interface but disable uevents, they
still pull-in the user interface of the firmware loader. If nobody
wants to fix them, the code for the common users of the firmware
loader should at least get rid of the userspace fallback to call out
to userspace. At that point the udev configure option would not matter
any more.
> Lastly, note that the plan is to drop all the firmware code from udev in the
> not too distant future, so it doesn't really maker much sense to add new
> functionality to that at this point.
Right, I think all is fine. It's something that people can control
with the kernel and udev configuration options. It's just that the
defaults of the kernel and udev don't match at the moment, because
they have different policies of setting default values.
Kay
prev parent reply other threads:[~2013-08-10 21:28 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-02 16:04 Slow firmware timeouts again (Re: [3.11 regression?] iwlwifi firmware takes two minutes to load) Andy Lutomirski
2013-08-02 16:21 ` Johannes Berg
2013-08-02 16:24 ` Andy Lutomirski
2013-08-02 16:28 ` Zbigniew Jędrzejewski-Szmek
2013-08-05 11:18 ` [systemd-devel] Slow firmware timeouts again (Re: [3.11 regression?] iwlwifi firmware takes two Kay Sievers
2013-08-05 16:09 ` Andy Lutomirski
2013-08-05 16:29 ` [PATCH] Change CONFIG_FW_LOADER_USER_HELPER to default n and don't select it Andy Lutomirski
2013-08-06 8:20 ` Maarten Lankhorst
2013-08-06 9:11 ` [systemd-devel] " Tom Gundersen
2013-08-06 9:17 ` Tom Gundersen
2013-08-06 16:08 ` Andy Lutomirski
2013-08-06 16:31 ` Bryan Kadzban
[not found] ` <CAG-2HqU=yyxomNTg9-2+bxMKP=e5_pdVT7bhB_CHhFzB-ac_mQ@mail.gmail.com>
2013-08-07 0:26 ` Andy Lutomirski
2013-08-07 7:52 ` [PATCH] udev: fail firmware loading immediately if no search path is defined Maarten Lankhorst
2013-08-07 21:24 ` Andy Lutomirski
[not found] ` <CAG-2HqUT3hbFPSEqYnJvBOgS6p4dKf=nhqZtzqS-on8FFe9ipA@mail.gmail.com>
2013-08-10 21:28 ` Kay Sievers [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAPXgP11LnVqTxsKUoLTLwtP-oxcekkNxmPG2X-R+2U9S4-dAgQ@mail.gmail.com \
--to=kay@vrfy.org \
--cc=bryan@kadzban.is-a-geek.net \
--cc=ilw@linux.intel.com \
--cc=johannes@sipsolutions.net \
--cc=linux-hotplug@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=m.b.lankhorst@gmail.com \
--cc=systemd-devel@lists.freedesktop.org \
--cc=teg@jklm.no \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).