Date: Thu, 24 Mar 2005 13:10:46 -0700 From: Scott Long <scottl@samsco.org> To: Dan Nelson <dnelson@allantgroup.com> Cc: "current@freebsd.org" <current@freebsd.org> Subject: Re: Reattach/redetect allways connected umass device - is it possible ? Message-ID: <42431EC6.1020303@samsco.org> In-Reply-To: <20050324195628.GC10908@dan.emsphone.com> References: <1110800717.1296.19.camel@localhost> <200503231411.46948.jhb@FreeBSD.org> <20050323154642.J37251@sasami.jurai.net> <42421D8D.5060502@elischer.org> <20050323205841.N37251@sasami.jurai.net> <77e48641fc04164b4c81cce75c42a38b@FreeBSD.org> <42431806.3060302@elischer.org> <20050324195628.GC10908@dan.emsphone.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Dan Nelson wrote: > In the last episode (Mar 24), Julian Elischer said: > >>John Baldwin wrote: >> >>>On Mar 23, 2005, at 9:00 PM, Matthew N. Dodd wrote: >>> >>>>On Wed, 23 Mar 2005, Julian Elischer wrote: >>>> >>>>>eject should imply a detach.. >>>>>i.e. I think your patch should call the detach code from the eject >>>>>code. >>>> >>>>Eject is for devices that support removable media. >> >>that doesn't mean that an eject shouldn't do all teh work for a >>detach as well. > > > I would be extremely surprised if a "camcontrol eject cd0" removed > /dev/cd0 :) Eject is for devices whose media can be removed, but the > device itself stays. > > Or are you just saying detach should do an eject (possibly a stop also) > first? > Let me reinforce this since there seems to be quite a bit of confusion. The 'stop' and 'eject' actions of camcontrol operate in the context of how they are defined in the SCSI world. That is, they send a particular command to the target that makes the target do the intended action. They do __not__ imply that CAM will detach the logical device, flush the buffer-cache, etc. There is a whole lot less magic here than I think that everyone is hoping for. Scott
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?42431EC6.1020303>