lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Mon, 29 Oct 2007 10:43:44 -0500 From: James Bottomley <James.Bottomley@...elEye.com> To: Jeff Garzik <jeff@...zik.org> Cc: LKML <linux-kernel@...r.kernel.org>, Linux-SCSI <linux-scsi@...r.kernel.org>, akpm@...ux-foundation.org Subject: Re: [PATCH v4 0/2] [SCSI] Asynchronous event notification infrastructure 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@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists