Date: Tue, 29 Mar 2005 13:18:30 +0200 From: Bernd Walter <ticso@cicely12.cicely.de> To: Stijn Hoop <stijn@win.tue.nl> Cc: ticso@cicely.de Subject: Re: Reattach/redetect allways connected umass device - is it possible ? Message-ID: <20050329111830.GG28703@cicely12.cicely.de> In-Reply-To: <20050329105200.GB57775@pcwin002.win.tue.nl> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050329111830.GG28703>