linux-kernel - Re: [patch 3/3] libata: handle AN interrupt

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: <460BB475.8000005@garzik.org>
Date:	Thu, 29 Mar 2007 08:43:33 -0400
From:	Jeff Garzik <jeff@...zik.org>
To:	James.Smart@...lex.Com
CC:	Kristen Carlson Accardi <kristen.c.accardi@...el.com>,
	linux-kernel@...r.kernel.org, akpm@...ux-foundation.org,
	linux-ide@...r.kernel.org, linux-scsi <linux-scsi@...r.kernel.org>
Subject: Re: [patch 3/3] libata: handle AN interrupt

James Smart wrote:
> For FC, we have several async events, and allow for LLDDs to send their own
> data or augment the generic transport event w/ additional LLDD-data. The
> infrastructure is implemented generically within the scsi midlayer.
> We are using Netlink w/ broadcasts to deliver the events rather than 
> kobject_uevent().
> We considered using a variant of kobject events, but the general 
> consensus was
> we didn't want to wrap transport events into the kobject infrastructure, 
> and using
> netlink natively allowed for transport data to be sent with the event. 
> Additionally,
> with the broadcast, we could support any number of tools concurrently 
> listening for
> change events. To date, this has worked very well. You may want to 
> consider this,
> especially if the types of events is expected to grow beyond the simple 
> "change"
> notification.


Fair enough, though I definitely lean towards some use of sysfs / device 
model for AN-style events specifically.  The media change events are 
generated by the device, not the transport, and we should definitely 
have an object in the device model that represents the device (if we 
don't already).

I could see transport-based events being delivered to a different 
endpoint, because transport events differ from device events.

	Jeff


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