All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff Garzik <jeff@garzik.org>
To: James Bottomley <James.Bottomley@SteelEye.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
	Linux-SCSI <linux-scsi@vger.kernel.org>,
	akpm@linux-foundation.org
Subject: Re: [PATCH v4 0/2] [SCSI] Asynchronous event notification	infrastructure
Date: Mon, 29 Oct 2007 11:58:30 -0400	[thread overview]
Message-ID: <47260326.9050701@garzik.org> (raw)
In-Reply-To: <1193672624.3383.25.camel@localhost.localdomain>

James Bottomley wrote:
> 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.

Think about about the values being exported by these sysfs attributes: 
they indicate whether or not that feature is supported.

Thus, using the presence/absence of an attribute to communicate the same 
thing would be redundant.

This suggestion adds a whole lot of complexity -- mirroring every change 
to sdev->supported_events by dynamically adding or removing attributes.

The current nice, simple, elegant bitops-based interface is suddenly a 
lot more cumbersome if forced to deal with attribute creation and disposal.

Finally, this additional complexity of dynamic attribute management also 
eliminates some key information:  userland can test the existence of the 
attribute to determine if that support is present in the kernel.

	Jeff

  reply	other threads:[~2007-10-29 15:58 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-29 14:42 [PATCH v4 0/2] [SCSI] Asynchronous event notification infrastructure Jeff Garzik
2007-10-29 14:42 ` [PATCH v4 1/2] SCSI: " Jeff Garzik
2007-10-29 15:51   ` James Bottomley
2007-10-29 16:07     ` Jeff Garzik
2007-10-29 16:17       ` James Bottomley
2007-10-29 16:29         ` Jeff Garzik
2007-10-29 17:01           ` James Bottomley
2007-10-29 21:31             ` [PATCH v5 0/2] SCSI asynchronous event notification API Jeff Garzik
2007-10-29 21:31               ` [PATCH v5 1/2] SCSI: add " Jeff Garzik
2007-10-29 21:31               ` [PATCH v5 2/2] libata: Utilize new SCSI event infrastructure Jeff Garzik
2007-10-29 14:42 ` [PATCH v4 " Jeff Garzik
2007-10-29 15:43 ` [PATCH v4 0/2] [SCSI] Asynchronous event notification infrastructure James Bottomley
2007-10-29 15:58   ` Jeff Garzik [this message]
2007-10-29 16:10     ` James Bottomley
2007-10-29 16:24       ` Jeff Garzik
2007-10-29 16:34         ` James Bottomley
2007-10-29 16:48           ` Jeff Garzik

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=47260326.9050701@garzik.org \
    --to=jeff@garzik.org \
    --cc=James.Bottomley@SteelEye.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.