From: Pavan Kondeti <pkondeti@codeaurora.org>
To: Greg KH <greg@kroah.com>
Cc: gregkh@suse.de, linux-usb@vger.kernel.org, linux-arm-msm@vger.kernel.org
Subject: Re: [RFC 1/2] USB: Notify OTG errors to user space via uevents
Date: Tue, 07 Dec 2010 09:50:22 +0530 [thread overview]
Message-ID: <4CFDB606.9000107@codeaurora.org> (raw)
In-Reply-To: <20101207035004.GA28875@kroah.com>
On 12/7/2010 9:20 AM, Greg KH wrote:
> On Mon, Dec 06, 2010 at 06:32:30PM -0800, pkondeti@codeaurora.org wrote:
>> Hi Greg,
>>
>>> On Mon, Dec 06, 2010 at 06:07:50PM +0530, Pavankumar Kondeti wrote:
>>>> OTG specification mandates no silent failures and all errors should
>>>> be reported to the user. The spec itself does not give the exact
>>>> error description. But recommends the error message to be self
>>>> explanatory. Provide otg_notify_error() utility for USB core and
>>>> OTG driver to send the error codes to user space. All the error
>>>> code values are described in include/linux/usb/ch9.h. The user space
>>>> application can listen to netlink socket and parse the buffer for
>>>> "MODULE=OTG" and "ERROR=n", where 'n' contains the error code.
>>>
>>> How are you going to listen to the netlink socket that is already
>>> grabbed by libudev?
>>>
>> Sorry. I never worked with udev. But I read udev documentation.
>> I thought an external script can be invoked by adding a udev rule
>> when MODULE=OTG is matched and ERROR value can be accessed
>> in the script via env variable.
>
> So, you created a new kernel/user ABI and never even tried it out to see
> how someone would even use it?
>
> {sigh}
>
> I'm afraid to ask if you actually tested this code, let alone compiled
> the thing...
>
I have tested this patch with a sample program @
http://www.kernel.org/doc/pending/hotplug.txt on busybox environment
where udevd is not running. After seeing your comments, I ran the same
program concurrently
with udev on Linux box.
>>> Please, if you really want to do this, create your own netlink socket,
>>> don't create new uevent messages that will just confused the existing
>>> tools out there, that's ripe for big problems.
>>>
>> I have seen examples in drivers sending uevents for notifying docking
>> station status (drivers/acpi/dock.c)
>
> That is when the hardware configuration of the system changes.
>
>> and when backlight brightness changes
>> (drivers/video/backlight/backlight.c).
>
> Again, hardware configuration status changed.
>
Documentation/filesystems/gfs2-uevents.txt says OFFLINE uevent is sent
upon file system errors.
>> So I have taken this approach.
>
> Please don't, this is NOT the way to get errors from the kernel back out
> to userspace, because, as you have noted, this is not how any other
> subsystem does it.
>
Thanks for your feedback. Is there any other way kernel can send errors
to user space asynchronously? is /dev/ interface acceptable?
--
Sent by a consultant of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
next prev parent reply other threads:[~2010-12-07 4:20 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-06 12:37 [RFC 1/2] USB: Notify OTG errors to user space via uevents Pavankumar Kondeti
2010-12-06 12:37 ` [RFC 2/2] USB: Notify OTG errors from hub driver Pavankumar Kondeti
2010-12-06 15:58 ` [RFC 1/2] USB: Notify OTG errors to user space via uevents Greg KH
2010-12-07 2:32 ` pkondeti
2010-12-07 3:48 ` Pavan Kondeti
2010-12-07 4:22 ` Greg KH
2010-12-07 3:50 ` Greg KH
2010-12-07 4:20 ` Pavan Kondeti [this message]
2010-12-07 4:42 ` Greg KH
2010-12-07 5:00 ` Pavan Kondeti
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=4CFDB606.9000107@codeaurora.org \
--to=pkondeti@codeaurora.org \
--cc=greg@kroah.com \
--cc=gregkh@suse.de \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-usb@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.