From owner-freebsd-current@FreeBSD.ORG Tue Mar 29 09:03:50 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9159616A4CE for ; Tue, 29 Mar 2005 09:03:50 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 15F1143D5F for ; Tue, 29 Mar 2005 09:03:50 +0000 (GMT) (envelope-from imp@BSDIMP.COM) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.13.3/8.13.1) with ESMTP id j2T921pi096794; Tue, 29 Mar 2005 02:02:01 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Tue, 29 Mar 2005 02:02:03 -0700 (MST) Message-Id: <20050329.020203.94399805.imp@bsdimp.com> To: phk@phk.freebsd.dk From: "M. Warner Losh" In-Reply-To: <40326.1112086648@critter.freebsd.dk> References: <20050329.014602.66168889.imp@bsdimp.com> <40326.1112086648@critter.freebsd.dk> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: current@freebsd.org cc: vova@fbsd.ru cc: mdodd@freebsd.org cc: freebsd-mobile@freebsd.org cc: julian@elischer.org cc: ticso@cicely.de Subject: Re: Reattach/redetect allways connected umass device - is it possible ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2005 09:03:50 -0000 In message: <40326.1112086648@critter.freebsd.dk> "Poul-Henning Kamp" writes: : In message <20050329.014602.66168889.imp@bsdimp.com>, "M. Warner Losh" writes: : : >Then we'd have to poll every second in a sane way to accomplish that. : >And finding the sane way that doesn't interfere with other bus usage : >may be tricky. : > : >Unless we're going to give events to the actual user (meaning userland : >entities that inform the user in a friendly way), I'd maintain that : >there's no difference between knowing that the media is ejected : >immediately, and the time of next use. The user experience will be : >the same either way. : : The filesystems could get an upcall now when the disk disappears, : but I have not had time to try to implement this sensibly in any : filesystems yet. This would be useful. : >In the short run, however, adding a few checks to critical parts of : >the path, like daopen, would make the user experience much better. : : Absolutely, I just get uncomfortable when I see too much "...we can : get away with...", I want us to stay the UNIX that solves problems : the right way. engineering is always a tradeoff between what we can easily get done to ease current pain, versus what we can get done later and better, but with more pain to the user between now and then. Warner