[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190905183305.GA22877@kroah.com>
Date: Thu, 5 Sep 2019 20:33:05 +0200
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: David Howells <dhowells@...hat.com>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>, rstrode@...hat.com,
swhiteho@...hat.com, nicolas.dichtel@...nd.com, raven@...maw.net,
keyrings@...r.kernel.org, linux-usb@...r.kernel.org,
linux-block <linux-block@...r.kernel.org>,
Christian Brauner <christian@...uner.io>,
LSM List <linux-security-module@...r.kernel.org>,
linux-fsdevel <linux-fsdevel@...r.kernel.org>,
Linux API <linux-api@...r.kernel.org>,
Linux List Kernel Mailing <linux-kernel@...r.kernel.org>
Subject: Re: Why add the general notification queue and its sources
On Thu, Sep 05, 2019 at 06:01:47PM +0100, David Howells wrote:
> (2) USB notifications.
>
> GregKH was looking for a way to do USB notifications as I was looking to
> find additional sources to implement. I'm not sure how he wants to use
> them, but I'll let him speak to that himself.
We are getting people asking for all sorts of "error reporting" events
that can happen in the USB subsystem that we have started to abuse the
KOBJ_CHANGE uevent notification for. At the same time your patches were
submitted, someone else submitted yet-another-USB-error patchset. This
type of user/kernel interface is much easier to use than abusing uevents
for USB errors and general notifications about what happened with USB
devices (more than just add/remove that uevents have).
So yes, I would like this, and I am sure the ChromeOS people would like
it too given that I rejected their patcheset with the assumption that
this could be done with the notification queue api "soon" :)
thanks,
greg k-h
Powered by blists - more mailing lists