On Mon, Dec 06, 2010 at 06:32:30PM -0800, pkondeti@xxxxxxxxxxxxxx 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...
> > 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.
> 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,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
