linux-kernel - Re: acpiphp makes noise on every lid close/open

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, 17 Nov 2006 16:31:28 +0000
From:	Matthew Garrett <mjg59@...f.ucam.org>
To:	Kristen Carlson Accardi <kristen.c.accardi@...el.com>,
	Pavel Machek <pavel@....cz>,
	kernel list <linux-kernel@...r.kernel.org>,
	ACPI mailing list <linux-acpi@...r.kernel.org>
Subject: Re: acpiphp makes noise on every lid close/open

On Fri, Nov 17, 2006 at 05:08:10PM +0100, David Weinehall wrote:

> Good question.  Personally I'd say we refuse to suspend when we have
> devices we *know* to be dock-devices etc mounted.

Kernel-level or userspace? IBM certainly used to sell bay-mounted hard 
drives, and while it's possible for a user to pull one out while the 
machine is suspended, I suspect that the general use case is probably 
for it to carry on being used.

Possibly what's needed is something like Apple's nullfs - force unmount 
the drive on suspend, and put a nullfs there instead. On resume, if the 
drive is still there, remount it. If not, userspace applications get 
upset about the missing drive but no data is lost. The downside to this 
approach would be trying to figure out how to get the drive remounted 
before the rest of userspace starts trying to scribble over it again...

-- 
Matthew Garrett | mjg59@...f.ucam.org
-
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/