linux-kernel - Re: [patch 2/4] Expose Power Management Policy option to users

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] [thread-next>] [day] [month] [year] [list]

Message-Id: <20070731091841.857d22bb.kristen.c.accardi@intel.com>
Date:	Tue, 31 Jul 2007 09:18:41 -0700
From:	Kristen Carlson Accardi <kristen.c.accardi@...el.com>
To:	Tejun Heo <htejun@...il.com>
Cc:	Arjan van de Ven <arjan@...radead.org>,
	Jeff Garzik <jeff@...zik.org>, James.Bottomley@...eleye.com,
	linux-scsi@...r.kernel.org, akpm@...ux-foundation.org,
	linux-kernel@...r.kernel.org, linux-ide@...r.kernel.org,
	edwintorok@...il.com, axboe@...nel.dk
Subject: Re: [patch 2/4] Expose Power Management Policy option to users

On Tue, 31 Jul 2007 23:45:25 +0900
Tejun Heo <htejun@...il.com> wrote:

> Anyways, I don't really think this attribute belongs to SCSI sysfs
> hierarchy.  There currently isn't any alternative but sysfs is part of
> userland visible interface and putting something into SCSI sysfs
> hierarchy just because libata doesn't have one doesn't look like a good
> idea.
> 
> sysfs isn't far from being detached from kobject and driver model.  I
> think it would be best to wait a bit and build proper libata sysfs
> hierarchy which won't have to be changed later when libata departs from
> SCSI.  Well, it isn't really a good way but IMHO it's better than
> sticking ATA power saving node into SCSI sysfs hierarchy.

"Wait a bit" could be a very long time.  Who is working on building this
new libata sysfs support now?  If the answer is "no one", which I think it 
may be, do you want to hold up a feature that actually helps many people
for possibly 6 months or more just because we have to go through scsi
right now for our sysfs interface?  on top of that, the last mail I 
got from James on this subject indicated that if we kept our granularity
large with the power savings levels, SCSI can actually take advantage of
this as well.  Sure, we may have to tweak things around later, but isn't
this what we do routinely?  Holding up valuable features from the kernel 
because things aren't perfect yet seems really broken. 

As far as your complaints about broken hardware go, keep in mind that
the patch set does provide a method of adding these disks to a blacklist,
so I don't see that as a problem.  And, the default for this feature is
"off", and user space would have to explicitly enable it.
-
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/