Date: Thu, 27 Aug 2015 18:06:38 -0600 From: jd1008 <jd1008@gmail.com> To: freebsd-questions@freebsd.org Subject: Re: Stop using a SATA drive Message-ID: <55DFA60E.5020209@gmail.com> In-Reply-To: <20150828020029.c3c53813.freebsd@edvax.de> References: <CAPi0psvT5aaHR7kU%2B28qwVDdutyMn7LjhFUGZRWctz4gGfgvgw@mail.gmail.com> <20150824214252.53aa04c6.freebsd@edvax.de> <55DEF869.1010202@sneakertech.com> <20150828000118.31f33a35.freebsd@edvax.de> <55DFA213.4030304@sneakertech.com> <20150828020029.c3c53813.freebsd@edvax.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On 08/27/2015 06:00 PM, Polytropon wrote: > On Thu, 27 Aug 2015 19:49:39 -0400, Quartz wrote: >>> That would surely be possible if the device in question >>> would implement a proper reaction to the "eject" command. >>> If it does, and how it does it, is up to the manufacturer. >>> Let's say you send the "eject" command to the drive - the >>> firmware then says goodbye to the host - the device file >>> disappears. >> ---- >> >>> Yes - mostly the software inside the device, which we >>> commonly call firmware. On USB, and to a certain extent, >>> on SATA, the device identifies to the system and enters >>> a communication with it: stating what device class, who >>> built it, which model, what capabilities are available >>> and so on. If the firmware is able to delete that >>> connection (which is, after all, a _data_ exchange, >>> not primarily an electric connection), the OS would >>> act accordingly by removing the device file entry. >> >> >> This line of reasoning doesn't make any sense, or at least it's not >> related to what I was talking about. Let me try phrasing it a different >> way: 'diskutil eject foo' will kick the disk off an OSX system and >> remove its entry from /dev, and this functionality works across all >> devices and adapters regardless of make or model. Whatever the 'eject' >> command is doing, it's clearly entirely software side within the OS*. >> Being software, FreeBSD should be capable of the same, especially >> considering both OSs have such a close common heritage. > I understand. This can be the OS-side of software which > causes the removal of the device entry as a "side effect". > While the disk device itself doesn't know how to eject > itself, the diskutil program deregisters the device entry > and removes the device from the current bus content list. > > Maybe there's even a "re-attach" command available to make > the device file reappear (for example by scanning the bus > again). > > This is possible. > > However, in regards of disk drives, I wouldn't call this > procedure "eject", but maybe better "detach". In retrospect, > ye olde "atacontrol" _had_ this functionality. See the dusty > historic manual for details. :-) > > Detach is correct, as that is how it is implemented in Sun OS, which also has a common heritage with BSD.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?55DFA60E.5020209>