From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753420AbXC2Mnj (ORCPT ); Thu, 29 Mar 2007 08:43:39 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753413AbXC2Mnj (ORCPT ); Thu, 29 Mar 2007 08:43:39 -0400 Received: from srv5.dvmed.net ([207.36.208.214]:52703 "EHLO mail.dvmed.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753370AbXC2Mnh (ORCPT ); Thu, 29 Mar 2007 08:43:37 -0400 Message-ID: <460BB475.8000005@garzik.org> Date: Thu, 29 Mar 2007 08:43:33 -0400 From: Jeff Garzik User-Agent: Thunderbird 1.5.0.10 (X11/20070302) MIME-Version: 1.0 To: James.Smart@Emulex.Com CC: Kristen Carlson Accardi , linux-kernel@vger.kernel.org, akpm@linux-foundation.org, linux-ide@vger.kernel.org, linux-scsi Subject: Re: [patch 3/3] libata: handle AN interrupt References: <460BB32F.8030904@emulex.com> In-Reply-To: <460BB32F.8030904@emulex.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -4.3 (----) X-Spam-Report: SpamAssassin version 3.1.8 on srv5.dvmed.net summary: Content analysis details: (-4.3 points, 5.0 required) Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org 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