Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758145AbXJ2Pn4 (ORCPT ); Mon, 29 Oct 2007 11:43:56 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751829AbXJ2Pns (ORCPT ); Mon, 29 Oct 2007 11:43:48 -0400 Received: from hancock.steeleye.com ([71.30.118.248]:40218 "EHLO hancock.sc.steeleye.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752608AbXJ2Pnr (ORCPT ); Mon, 29 Oct 2007 11:43:47 -0400 Subject: Re: [PATCH v4 0/2] [SCSI] Asynchronous event notification infrastructure From: James Bottomley To: Jeff Garzik Cc: LKML , Linux-SCSI , akpm@linux-foundation.org In-Reply-To: <15624bab8dc0206e384ac8314257a900e60127c1.1193668176.git.jeff@garzik.org> References: <15624bab8dc0206e384ac8314257a900e60127c1.1193668176.git.jeff@garzik.org> Content-Type: text/plain Date: Mon, 29 Oct 2007 10:43:44 -0500 Message-Id: <1193672624.3383.25.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.10.3 (2.10.3-4.fc7) Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1823 Lines: 43 On Mon, 2007-10-29 at 10:42 -0400, Jeff Garzik wrote: > This is the next revision of the SCSI event notification infrastructure > patchset, enabling SATA Asynchronous Notification ("AN") for CD/DVD > devices that support it. > > For devices that support SATA AN (only very recent ones do), this means > that HAL and other userspace utilities no longer need to repeatedly poll > the CD/DVD device to determine if the user has changed the media. > > This revision takes into account James' comments from earlier today, > modulo the following notes: > > * I think the various event attributes should always be present, > for all devices at all times. If various events are not supported, > the attribute will of course return zero (false, not supported). Actually, I don't think so. We have precedent for this in the transport classes: if a device doesn't support a feature, we don't export the flag for that feature through sysfs. This allows not only feature control, but an immediate view of the device capabilities simply by viewing the sysfs directory. I think this functionality is very easy to layer in, so there's no reason not to do it. > * I do not think this work should be blocked behind a revamp > of the attribute group interface. Assuming gregkh or kay ack, it won't be. > * I was slack and did not bother to implement the 'set' operation > for the attributes. This can easily be done at a later time in a > separate patch. It is not a merge stopper to have the driver > exclusively control the event mask, rather than driver+sysfs. James - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/