linux-kernel - Re: [PATCH 12/12] usb: use IRQ watching

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20100615174742.GA21616@suse.de>
Date:	Tue, 15 Jun 2010 10:47:42 -0700
From:	Greg KH <gregkh@...e.de>
To:	Tejun Heo <tj@...nel.org>
Cc:	Kay Sievers <kay.sievers@...y.org>, mingo@...e.hu,
	tglx@...utronix.de, bphilips@...e.de, yinghai@...nel.org,
	akpm@...ux-foundation.org, torvalds@...ux-foundation.org,
	linux-kernel@...r.kernel.org, jeff@...zik.org,
	linux-ide@...r.kernel.org, stern@...land.harvard.edu,
	khali@...ux-fr.org
Subject: Re: [PATCH 12/12] usb: use IRQ watching

On Tue, Jun 15, 2010 at 07:36:12PM +0200, Tejun Heo wrote:
> Hello,
> 
> On 06/15/2010 03:36 PM, Kay Sievers wrote:
> > Yeah, I'm pretty sure that's not what we want. We want structured
> > data, and a generic channel to pass all sort of errors through, and a
> > userspace part to handle it in a sane way. Many error sources may also
> > not have a device path in /sys, and therefore no uevent to send.
> > Uevents/udev just seem so convinient because it's already there, but I
> > think, has too many limitations to provide the needed functionality.
> > Besides the fact that nothing listens to these events in userspace
> > today -- it's a lot more to think through and work on than passing
> > things through uevents, especially some generic classification and
> > structured data passing, which is needed, instead of the current
> > free-text 'dmsg' or the property-based stuff in uevents. I'm very sure
> > it's the wrong facility to use.
> 
> Yeah, well, if you say so.  It would be very nice to have report this
> type of critical events in somewhat formatted way so that they can be
> processed automatically and presented to the user in more accessible
> manner.  I doubt requiring strict structure would work in the long
> run.  It'll likely end up being able to cover only portion of what's
> originally designed and and stagnate in time.  I think control
> information including identification and severity + free form string
> would be much more manageable.
> 
> It would really be great to have something like that.  I can easily
> think of several libata events the user should be notified of from the
> top of my head but currently are buried in dmesg.

That is what Andi Kleen and others are working on at the moment.  I
think he's posted to lkml about it, and there are going to be more talks
about it at the Plumbers conference this year.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/