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]
Date:	Fri, 13 Jul 2007 15:23:51 +0800
From:	Zhang Rui <rui.zhang@...el.com>
To:	Satyam Sharma <satyam.sharma@...il.com>
Cc:	Henne <henne@...htwindheim.de>,
	Arjan van de Ven <arjan@...radead.org>,
	"Brown, Len" <len.brown@...el.com>, linux-acpi@...r.kernel.org,
	akpm@...ux-foundation.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH][ACPI][BUTTON] remove procfs-interface

On Fri, 2007-07-13 at 03:07 +0800, Satyam Sharma wrote:
> On 7/12/07, Zhang, Rui <rui.zhang@...el.com> wrote:
> > Well, the ACPI sysfs conversion is not finished yet
> > [...]
> > I'm not sure if the button sysfs I/F is already finished.
> > We'd better make a double check. :)
> 
> Ok, this sounds reasonable.
> 
> > and some user space tools still use the ACPI procfs.
> 
> But this does *not*, IMHO. It quite defeats the whole concept of
> feature-removal-schedule.txt. I think that file exists precisely
> because we cannot gratuitously break userspace interfaces just
> like that, but when something gets put up there with a removal date
> that is a good one year in the future, and userspace tools _still_
> continue to use it ... then, I suspect something's seriously wrong.
> 
Hi, Satyam,
Here I mean the sysfs conversion is not finished, like some ACPI
device/driver attributes.
i.e. we don't have the alternative in sysfs for all the ACPI proc I/F,
which means that part of the ACPI proc I/F are still needed.

> Either the feature-removal-schedule.txt file has become something
> that users don't even bother checking, or else, they _know_ that
> even if they don't bother keeping up with the pace in kernel-land,
> that interface still won't go away (because they're still using it!).
> In both the above cases, it appears that file itself has become
> irrelevant and a "feature" that could be "removed" ... :-)

Thanks,
Rui
-
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