Date: Tue, 3 Jul 2007 00:43:30 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: Nate Lawson <nate@root.org> Cc: phk@phk.freebsd.dk, marck@rinet.ru, "M. Warner Losh" <imp@bsdimp.com>, current@freebsd.org Subject: Re: GEOM weirdness with SD flash reader? Message-ID: <20070703003353.B72943@fledge.watson.org> In-Reply-To: <46897A6A.9020909@root.org> References: <54253.1183351841@critter.freebsd.dk> <4688878F.20406@root.org> <20070701.233153.-1343615328.imp@bsdimp.com> <4688947D.4040803@root.org> <20070702150825.L61395@fledge.watson.org> <46897A6A.9020909@root.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 2 Jul 2007, Nate Lawson wrote: >>>> This doesn't belong in devd. >>>> >>>> Robert has patches to bring new geom entries into the realm of devd. >>> >>> URL? >> >> This is from quite a long time ago, so likely needs massaging to apply. >> >> http://www.watson.org/~robert/freebsd/geom_devctl.diff >> >> The idea is straight forward: when a new geom device is discovered, we >> issue a notification, which allows devd to respond to events above the >> newbus layer -- i.e., discover of an fdisk partition table, swap-backed md >> device, attachment of a new software RAID layer, arrival of a volume by >> volume name, arrival of a ZFS volume, etc. > > Minor comments: * Functions are small enough that I doubt they need a whole > new C file * devd string looks a little weird ("at on"?) > > I don't think this helps. When usb calls scsi_da calls disk_create(), > userland will get a GEOM devd notice. Now what happens? > > I assume it might be: some script runs, does camcontrol inquiry <DEVICE>, > notes that it is removable, then forks a proc that does the above sleep loop > I described? > > I don't think that's any different from what I described except I put it as > internal to devd, not an external script. I don't care where it goes so > that's fine with me. > > After the device is unmounted and the media potentially goes away, who > figures out that the poll loop should start up again? This intentionally uncommitted patch comes without warranty, express or implied. :-) This patch was not intended to solve the problem being discussed here -- it was intended to make it easier to write an automounter that responds to asynchronous notifications of GEOM-layer events, not deal with the lack of asynchronous notifications out of the SCSI and/or hardware to the GEOM layer. GEOM relies on these notifications in order to decide when to start the "tasting" process, which is why they aren't picked up. If the SCSI layer does discover at some point later when I/O is issued, it does sound like some sort of disk_tickle(9) API is required so that SCSI can request a bit of reevaluation of matters without actually destroying and recreating the entire stack. I have no opinions about how it should happen if no such asynchronous notification is generated by the hardware. :-) Robert N M Watson Computer Laboratory University of Cambridge
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070703003353.B72943>