Date: Wed, 26 May 2010 11:21:12 -0700 From: Matthew Jacob <mj@feral.com> To: Alexander Motin <mav@FreeBSD.org> Cc: freebsd-scsi@FreeBSD.org Subject: Re: patches for CAM SCSI probing, etc. Message-ID: <4BFD6698.9040100@feral.com> In-Reply-To: <4BFC1C57.4080703@FreeBSD.org> References: <4BFB3985.1030301@FreeBSD.org> <mailpost.1274804732.4568033.10040.mailing.freebsd.scsi@FreeBSD.cs.nctu.edu.tw> <4BFC1C57.4080703@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Okay, I see your point. I would assert that for SCSI there should only be one probe active at any time for any given nexus *or* I should adopt your approach and restart the state machine if additional commands show up. It's also true that scans ought to be limited from user space. There's nothing to stop one from running 1000 camcontrol rescans from user space, and that effectively hangs the system as it's spending all of its time running stuff for them, so I might put a bit of serialization in here. Thoughts? > Matthew Jacob wrote: > >> Part of the reason I went the way you had done for ATA is to try and >> guarantee one and one only probe action at a time per nexus. >> > But in ATA I am restarting probe from the begining when new request > arrive. Look on "softc->restart". > > >>> you are slightly changing semantics of device probe. Previously, probe >>> call means warranty that device will be probed from the beginning after >>> the moment of request. It is very important for ATA, as probe function >>> also initializes device, that is mandatory if probe is called as result >>> of device reset. SCSI devices probably don't need that initialization, >>> but what if probe was called due to inquiry change status received >>> during probe sequence running? Are you sure you won't loose events here? >>> >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4BFD6698.9040100>