From mboxrd@z Thu Jan 1 00:00:00 1970 From: Oliver Neukum Subject: Re: Flames over -- Re: Which is simpler? Date: Mon, 20 Feb 2006 07:55:57 +0100 Message-ID: <200602200755.57699.oliver@neukum.org> References: <43F89F55.5070808@cfl.rr.com> <200602192144.57748.oliver@neukum.org> <20060219130243.52af0782.akpm@osdl.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: In-Reply-To: <20060219130243.52af0782.akpm@osdl.org> Content-Disposition: inline Sender: linux-kernel-owner@vger.kernel.org To: Andrew Morton Cc: stern@rowland.harvard.edu, psusi@cfl.rr.com, pavel@suse.cz, torvalds@osdl.org, mrmacman_g4@mac.com, alon.barlev@gmail.com, linux-kernel@vger.kernel.org, linux-pm@lists.osdl.org List-Id: linux-pm@vger.kernel.org Am Sonntag, 19. Februar 2006 22:02 schrieb Andrew Morton: > Oliver Neukum wrote: > > > > Am Sonntag, 19. Februar 2006 21:02 schrieb Andrew Morton: > > > For a), the current kernel behaviour is what we want - make the t= hing > > > appear at a new place in the namespace and in the hierarchy. =A0T= hen > > > userspace can do whatever needs to be done to identify the device= , and > > > apply some sort of policy decision to the result. > >=20 > > How? If you have a running user space the connection to the open fi= les > > is already severed, as any access in that time window must fail. >=20 > That's a separate issue, which we haven't discussed yet. =A0We have a= device > which has gone away and which might come back later on. =A0Presently = we will > return an I/O error if I/O is attempted in that window. =A0Obviously = we'll > need to do something different, such as block reads and block or defe= r writes. But how do you handle memory management? If you simply block writes, the system will stall random tasks launderi= ng pages, including those needed to make progress. Even syncing before suspend won't help you, as a running user space may dirty pages. And what about the rootfs? Oliver