[patch 0/7] Asynchronous Notification for ATAPI devices (resend)

[patch 0/7] Asynchronous Notification for ATAPI devices (resend)

[Kristen Carlson Accardi]

Hi Jeff,
Here are the AN patches again, they have not changed with the exception
of patch #1, which does set the host flag in board_ahci and board_ahci_pi
now (thanks Tejun).

This patch series implements Asynchronous Notification (AN) for SATA
ATAPI devices as defined in SATA 2.5 and AHCI 1.1 and higher.  Drives
which support this feature will send a notification when new media is
inserted and removed, preventing the need for user space to poll for
new media.  This support is exposed to user space via a flag that will
be set in /sys/block/sr*/capability_flags.  If the flag is set, user
space can disable polling for the new media, and the genhd driver will
send a KOBJ_CHANGE event with the envp set to MEDIA_CHANGE_EVENT=1.

Note that this patch only implements support for directly attached
drives - AN with drives attached to a port multiplier requires 
additional changes.

Thanks!
Kristen

-- 

Re: [patch 0/7] Asynchronous Notification for ATAPI devices (resend)

[Jeff Garzik]

Kristen Carlson Accardi wrote:
> Hi Jeff,
> Here are the AN patches again, they have not changed with the exception
> of patch #1, which does set the host flag in board_ahci and board_ahci_pi
> now (thanks Tejun).
> 
> This patch series implements Asynchronous Notification (AN) for SATA
> ATAPI devices as defined in SATA 2.5 and AHCI 1.1 and higher.  Drives
> which support this feature will send a notification when new media is
> inserted and removed, preventing the need for user space to poll for
> new media.  This support is exposed to user space via a flag that will
> be set in /sys/block/sr*/capability_flags.  If the flag is set, user
> space can disable polling for the new media, and the genhd driver will
> send a KOBJ_CHANGE event with the envp set to MEDIA_CHANGE_EVENT=1.
> 
> Note that this patch only implements support for directly attached
> drives - AN with drives attached to a port multiplier requires 
> additional changes.

Patches look OK to me...  it will take some coordination for the 
non-libata bits.  I think Andrew mentioned some of this.  And if the 
SCSI bits get stuck in the SCSI maintainer's bit bucket, let me know.

	Jeff