From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753439AbXC2NE5 (ORCPT ); Thu, 29 Mar 2007 09:04:57 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753433AbXC2NE5 (ORCPT ); Thu, 29 Mar 2007 09:04:57 -0400 Received: from emulex.emulex.com ([138.239.112.1]:42136 "EHLO emulex.emulex.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753427AbXC2NE4 (ORCPT ); Thu, 29 Mar 2007 09:04:56 -0400 Message-ID: <460BB94D.8060802@emulex.com> Date: Thu, 29 Mar 2007 09:04:13 -0400 From: James Smart Reply-To: James.Smart@Emulex.Com User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Jeff Garzik 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> <460BB475.8000005@garzik.org> In-Reply-To: <460BB475.8000005@garzik.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Mar 2007 13:04:13.0386 (UTC) FILETIME=[BFA12AA0:01C77202] Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Jeff Garzik wrote: > 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 Sure... although what object the event relates to is really a component of either the socket (1 per object) or an object identifier within the event message (1 socket with message headers). The transport, as we use it, really isn't the object and isn't the one generating the events, it's just a well-known listening point and serves as a nice library to insulate drivers from the implementation. Granted, what's being proposed now is fairly simple, so sysfs works fine. But if you grow at all, you'll be confronted with the multiple-readers and payload issues that we had. -- james