From owner-freebsd-current@FreeBSD.ORG Tue Mar 29 11:21:03 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 2257016A4CE; Tue, 29 Mar 2005 11:21:03 +0000 (GMT) Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2765443D5F; Tue, 29 Mar 2005 11:21:02 +0000 (GMT) (envelope-from ticso@cicely12.cicely.de) Received: from cicely5.cicely.de (cicely5.cicely.de [10.1.1.7]) (authenticated bits=0)j2TBKnsf039613 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Tue, 29 Mar 2005 13:20:51 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (cicely12.cicely.de [IPv6:3ffe:400:8d0:301::12]) by cicely5.cicely.de (8.12.10/8.12.10) with ESMTP id j2TBKLVK095433 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Mar 2005 13:20:22 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (localhost [127.0.0.1]) by cicely12.cicely.de (8.12.11/8.12.11) with ESMTP id j2TBKLqj033669; Tue, 29 Mar 2005 13:20:21 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.12.11/8.12.11/Submit) id j2TBIUwB033665; Tue, 29 Mar 2005 13:18:30 +0200 (CEST) (envelope-from ticso) Date: Tue, 29 Mar 2005 13:18:30 +0200 From: Bernd Walter To: Stijn Hoop Message-ID: <20050329111830.GG28703@cicely12.cicely.de> References: <20050328131318.GC14532@cicely12.cicely.de> <31970.1112016818@critter.freebsd.dk> <20050329.011148.69987814.imp@bsdimp.com> <20050329081605.GA57775@pcwin002.win.tue.nl> <20050329104347.GB69824@cirb503493.alcatel.com.au> <20050329105200.GB57775@pcwin002.win.tue.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050329105200.GB57775@pcwin002.win.tue.nl> X-Operating-System: FreeBSD cicely12.cicely.de 5.2-CURRENT alpha User-Agent: Mutt/1.5.6i X-Spam-Status: No, hits=0.0 required=3.0 tests=none autolearn=no version=2.64 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on cicely12.cicely.de X-Mailman-Approved-At: Tue, 29 Mar 2005 12:54:13 +0000 cc: current@freebsd.org cc: vova@fbsd.ru cc: Peter Jeremy cc: mdodd@freebsd.org cc: freebsd-mobile@freebsd.org cc: phk@phk.freebsd.dk cc: julian@elischer.org cc: ticso@cicely.de cc: "M. Warner Losh" 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 Reply-To: ticso@cicely.de 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 11:21:03 -0000 On Tue, Mar 29, 2005 at 12:52:00PM +0200, Stijn Hoop wrote: > On Tue, Mar 29, 2005 at 08:43:47PM +1000, Peter Jeremy wrote: > > On Tue, 2005-Mar-29 10:16:05 +0200, Stijn Hoop wrote: > > > From a desktop user experience point of view, it is rather nice to get > > > a notification if and when removable media disappears, without > > > continously polling said media. > > > > There's no reason why the kernel couldn't regularly poll removable media > > as long as it didn't interfere with normal operation of the device or > > intrude upon the user (who remembers Amiga FDD's ticking?). > > Powersaving reasons (as has been stated in this thread already, I > believe) come to mind. Or, in some cases, physical wear & tear on the > hardware -- although I believe it's not the case for regular USB flash > drives, I can imagine an implementation that needs to access the > physical media in order to determine status (cardreaders?). Wear shouldn't be a problem. All recent media types have mechanism for that. > But as Poul-Henning said, it's up to the drivers themselves to resort > to polling if needed. Yes - and the most interesting these days is the da driver. > > > This statement intentionally ignores > > > the question of how to get such an event through the kernel to > > > userspace. > > > > I don't believe this is a problem. For a command line interface, you > > run "ls" and get a snapshot of the directory contents - you don't expect > > the output from an old "ls" to magically update itself when a file is > > deleted, you re-run "ls". GUI file browsers are more of a problem but > > as long as the browser doesn't cache the results from one invocation to > > another, this wouldn't seem to be a problem. > > I was not thinking of contents exactly; more of the desktop user > experience where, by inserting an USB drive, an icon appears on the > desktop. That icon should be removed when the drive is removed again. > Other similar usecases abound. But since you are talking about drive removal there shouldn't be a real problem. OK - GEOM and CAM could issue newbus notifications, but I think that's already on someones todo list. So far you get an umass attachment and easily process the rest. > > In any case, the majority of the computer users seem quite happy with > > a user interface that, upon ejecting a removable medium and inserting > > a different medium, will happily display the union of the contents of > > the old and new media. > > I might be misreading the sarcasm here, but I for one am not happy > with the mixed contents. I'm already a bit weary of using removable > media with FreeBSD because I'm unsure what works and what does not. > This is a situation I would like to remedy. Everything works fine as long as you trigger a GEOM rescan after media exchange. drive exchange doesn't need any special handling. -- B.Walter BWCT http://www.bwct.de bernd@bwct.de info@bwct.de