From: Michael Brown <mebrown@michaels-house.net>
To: Kay Sievers <kay.sievers@vrfy.org>
Cc: Doug Warzecha <Douglas_Warzecha@dell.com>,
Jean Delvare <khali@linux-fr.org>,
Greg Kroah-Hartman <gregkh@suse.de>,
linux-kernel@vger.kernel.org,
Mauro Carvalho Chehab <mchehab@infradead.org>,
Matt Domsch <Matt_Domsch@dell.com>
Subject: Re: Class device namespaces
Date: Wed, 29 Apr 2009 16:28:35 -0500 [thread overview]
Message-ID: <437908170904291428k445fc8fdy9b3bb4e78ee91018@mail.gmail.com> (raw)
In-Reply-To: <ac3eb2510904291210y6d0a4199gc1800d0d02d0d7c6@mail.gmail.com>
On Wed, Apr 29, 2009 at 2:10 PM, Kay Sievers <kay.sievers@vrfy.org> wrote:
> Udev runs exactly at the time you create the device, and is not
> unlikely faster than your polling, at least not predictable slower.
> And it will cancel all requests which can not be fulfilled by udev
> itself.
>
> I strongly recommend switching to a different solution, you can not
> use the firmware_class interface on any udev system, the interface is
> already taken, and it's a single-user interface the way it is
> implemented today. That it seems to work for you, is pure luck, I
> guess. :)
Is there a safe/easy way to tell udev that we will handle a particular
request? I cant say that I've ever seen any problems due to udev
cancelling a firmware request. In fact, if I manually trigger a
request using "echo" from the cmdline, I dont see udev take any action
with the dell_rbu device. eg (Fedora 10, udev-127-5.fc10):
# find /sys -name dell_rbu
/sys/devices/platform/dell_rbu
/sys/bus/platform/devices/dell_rbu
/sys/module/dell_rbu
[root@duo dell_rbu]# echo "init" > /sys/devices/platform/dell_rbu/image_type
[root@duo dell_rbu]# find /sys -name dell_rbu
/sys/devices/platform/dell_rbu
/sys/devices/platform/dell_rbu/firmware/dell_rbu
/sys/bus/platform/devices/dell_rbu
/sys/class/firmware/dell_rbu
/sys/module/dell_rbu
[root@duo dell_rbu]# ll /sys/class/firmware/dell_rbu/
total 0
-rw-r--r-- 1 root root 0 2009-04-29 16:25 data
lrwxrwxrwx 1 root root 0 2009-04-29 16:25 device -> ../../../dell_rbu
-rw-r--r-- 1 root root 4096 2009-04-29 16:25 loading
drwxr-xr-x 2 root root 0 2009-04-29 16:25 power
lrwxrwxrwx 1 root root 0 2009-04-29 16:25 subsystem ->
../../../../../class/firmware
-rw-r--r-- 1 root root 4096 2009-04-29 16:25 uevent
[root@duo dell_rbu]#
[root@duo dell_rbu]# echo 0 > /sys/class/firmware/dell_rbu/loading
[root@duo dell_rbu]#
[root@duo dell_rbu]# find /sys -name dell_rbu
/sys/devices/platform/dell_rbu
/sys/bus/platform/devices/dell_rbu
/sys/module/dell_rbu
I dont see any of the behaviour that you have talked about. If I let
it sit there for hours, it will stay at that state. It only closes up
the request_firmware() request when I echo 0 > loading.
At this point, we have had this interface in the upstream kernel.org
kernel since 2.6.14 and have a pretty huge legacy codebase that relies
on this behaviour. We need to make sure that the current behaviour
remains.
--
Michael
next prev parent reply other threads:[~2009-04-29 21:28 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-29 15:48 Class device namespaces Jean Delvare
2009-03-29 16:36 ` Kay Sievers
2009-03-30 8:49 ` Jean Delvare
2009-03-30 11:24 ` Kay Sievers
2009-04-26 6:54 ` Jean Delvare
2009-04-26 12:44 ` Matt Domsch
2009-04-26 13:01 ` Matt Domsch
2009-04-27 15:30 ` Jean Delvare
2009-04-27 17:30 ` Matt Domsch
2009-04-26 13:42 ` Kay Sievers
2009-04-27 16:00 ` Jean Delvare
2009-04-27 21:57 ` Kay Sievers
2009-04-28 8:08 ` Jean Delvare
2009-04-28 12:36 ` Kay Sievers
2009-04-29 12:19 ` Jean Delvare
2009-04-27 13:20 ` Michael E Brown
2009-04-27 15:27 ` Jean Delvare
2009-04-27 17:23 ` Michael Brown
2009-04-28 8:10 ` Jean Delvare
2009-04-28 17:39 ` Doug Warzecha
2009-04-28 17:46 ` Kay Sievers
2009-04-28 21:58 ` Doug Warzecha
2009-04-29 1:42 ` Kay Sievers
2009-04-29 3:19 ` Michael Brown
2009-04-29 10:30 ` Kay Sievers
2009-04-29 17:00 ` Michael Brown
2009-04-29 19:10 ` Kay Sievers
2009-04-29 21:28 ` Michael Brown [this message]
2009-04-29 21:53 ` Kay Sievers
2009-04-30 15:18 ` David Dillow
2009-04-30 16:34 ` Kay Sievers
2009-04-28 19:06 ` Jean Delvare
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=437908170904291428k445fc8fdy9b3bb4e78ee91018@mail.gmail.com \
--to=mebrown@michaels-house.net \
--cc=Douglas_Warzecha@dell.com \
--cc=Matt_Domsch@dell.com \
--cc=gregkh@suse.de \
--cc=kay.sievers@vrfy.org \
--cc=khali@linux-fr.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mchehab@infradead.org \
/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