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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <49E36F13.2010903@garzik.org>
Date:	Mon, 13 Apr 2009 12:57:55 -0400
From:	Jeff Garzik <jeff@...zik.org>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
CC:	Mark Lord <liml@....ca>, linux-ide@...r.kernel.org,
	LKML <linux-kernel@...r.kernel.org>, gwendal@...gle.com
Subject: Re: [PROPOSED] ata: Report 16/32bit PIO as best we can

Alan Cox wrote:
> On Mon, 13 Apr 2009 12:32:57 -0400
> Jeff Garzik <jeff@...zik.org> wrote:
> 
>>> I'm not sure sysfs helps much anyway - you have to open the device file
>>> and keep it open while accessing the sysfs nodes anyway (something huge
>>> numbers of apps hopelessly fail to do so)  
>> FWIW...  here is the sysfs work I referred to (in a message sent several 
>> days ago in this thread)...
>>
>> http://lwn.net/Articles/294608/
> 
> Which indeed shows the same problems. There is nothing to stop changes in
> the rest of the topology from causing me to write to the sysfs at the
> wrong moment and reconfigure/misconfigure a different object to the one
> intended.

The horse has already left the barn, on that one...

Google's ata transport class is consistent with existing transport class 
work in the kernel.  It is also consistent with recent admonitions in 
the osdblk thread, regarding the "one piece of data per sysfs file" rule.

Personally I think a netlink-like approach to managing and controlling 
SAS and ATA would be better, but that's not what gets merged...

	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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ