linux-kernel - Re: [patch 2/3] libata: expose AN support to user space via sysfs

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

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 28 Mar 2007 22:19:53 -0400
From:	Jeff Garzik <jgarzik@...ox.com>
To:	Tejun Heo <htejun@...il.com>
CC:	Kristen Carlson Accardi <kristen.c.accardi@...el.com>,
	linux-kernel@...r.kernel.org, akpm@...ux-foundation.org,
	linux-ide@...r.kernel.org, linux-scsi <linux-scsi@...r.kernel.org>
Subject: Re: [patch 2/3] libata: expose AN support to user space via sysfs

Tejun Heo wrote:
> Jeff Garzik wrote:
>> Kristen Carlson Accardi wrote:
>>> Allow user space to determine if an ATAPI device supports
>>> async notification (AN) of media changes.  This is done by
>>> adding a new sysfs file "async_notification" to genhd.
>>> If the file reads 1, then the device supports async notification.  If 
>>> the file reads 0, it does not. A flag is set in the generic disk to 
>>> indicate whether
>>> or not AN is supported.  This flag is set by the SCSI
>>> subsystem when it registers with add_disk.  The SCSI
>>> system gets information from libata on whether the
>>> device supports AN during dev_configure.
>>> Signed-off-by: Kristen Carlson Accardi <kristen.c.accardi@...el.com>
>>>
>>
>> 3) I would make the contents of 'media_change_events' be a list of 
>> flags, rather than a boolean.  Thus, when AN is present, 
>> media_change_events would return "AN\n".  It would return "\n" (no 
>> flags) when AN is absent.  This permits future expansion of this 
>> capabilities reporting variable.
> 
> I'm not sure about this.  AN is kind of specific term for ATA while 
> media change event is generic.  So, I think the original approach is 
> okay.  No matter how the actual thing is implemented, it's the same 
> media change event and as long as event delivery interface is the same, 
> upper layer shouldn't care about how it's done.

AN is a generic concept that I feel will propagate elsewhere.

Though perhaps it should be in a 'capability_flags' file rather than a 
'media_change_event' file.

	Jeff



-
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/