Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!munnari.OZ.AU!news.mel.connect.com.au!news.mira.net.au!inquo!news.seinf.abb.se!nooft.abb.no!Norway.EU.net!nntp.uio.no!news.cais.net!news.mathworks.com!uunet!inXS.uu.net!news.artisoft.com!usenet
From: Terry Lambert <terry@lambert.org>
Newsgroups: comp.unix.bsd.freebsd.misc
Subject: Re: Anything like Solaris's volume management?
Date: Mon, 01 Jul 1996 16:45:49 -0700
Organization: Me
Lines: 77
Message-ID: <31D8632D.181E0B42@lambert.org>
References: <4r1iq3$h2d@oink.cs.utexas.edu> <31D47B44.CE6D7D4@lambert.org> <4r3p00$s7j@uriah.heep.sax.de>
NNTP-Posting-Host: hecate.artisoft.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: Mozilla 2.01 (X11; I; Linux 1.1.76 i486)
J Wunsch wrote:
] > > I was wondering if FreeBSD offered anything similar to
] > > vold on Solaris (e.g. automatically mount CD-ROMs and
] > > theoretically other things when they are inserted into
] > > the drive)?
] >
] > Not yet. It requires management of "device arrival" events,
] > integration of devfs, and some significant changes to the mount
] > code (most of which have already been submitted).
]
] In particular, PeeCee floppy drives don't even have a reliable
] method to find out about whether there's a medium in the drive,
] so don't expect them to generate ``device arrival'' events.
Removable media drives issue "device arrival" when they probe
true.
I think you mean "media arrival".
In general, there are two cases:
1) Attempt a read at "device arrival". If the read does
not fail (ie: multiple reads for format detection may
be necessary), then "media arrival" can be signalled.
2) The media is not present or is of an unrecognized
format, and therefore signalling "media arrival"
would be inappropriate. But since the device exists,
an access point is allowable. Media can be checked
for "arrival" on an attempted access.
If a media is determined to have "arrived", then the arrival
can also signal "departure" of previous media (if any).
Most 3.5" floppies support media change notification. If the
controller or the system software is not prepared to deal
with this, then you have what is technically called "crap"
hardware.
People who buy "crap" can still get manual media change
notification using a "change" utility. Use of a manual
utility is a disincentive for future purchases of "crap".
Eventually, no one buys "crap", and it goes away.
"Device arrival" events (as opposed to "media arrival" events)
have value in that they allow automounting of fixed media, or
removable devices which support arrival deprature/arrival
notification (PCMCIA, for example).
Media arrival events are desirable, but not required for a
system to be implemented that can deal with the events
effectively. For instance, the crappy non-SCSI IOmega
"ZIP" drives do not register with the Windows95 device
management as removable media. IOmega supplies their own
TSD, and implements it incorrctly to function within the
Windows95 device framework (example: try to install the
Windows95 VFAT32 release software, which is going to become
standard equipment in OEM Windows95 BOM's later this year:
it will fail to operate on the "ZIP" drive because the TSD
was not correctly implemented).
"Crap" hardware is a problem for everyone, but should not be
the limiting factor on software, or you will end up with
nothing but "crap" software, guaranteed to work on "crap"
hardware, and perform like it is talking to "crap" hardware,
even which you spend the $30 extra to get "non-crap" hardware.
Terry Lambert
terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.