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: <4C17BA0C.4010208@kernel.org>
Date:	Tue, 15 Jun 2010 19:36:12 +0200
From:	Tejun Heo <tj@...nel.org>
To:	Kay Sievers <kay.sievers@...y.org>
CC:	Greg KH <gregkh@...e.de>, 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

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.

Thanks.

-- 
tejun
--
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/