Date: Fri, 05 Jan 2007 11:27:40 -0700 From: Scott Long <scottl@samsco.org> To: mjacob@freebsd.org Cc: freebsd-scsi@freebsd.org Subject: Re: CAM rescanner thread? Message-ID: <459E989C.2020602@samsco.org> In-Reply-To: <459E97E6.4000603@samsco.org> References: <20070104225519.Q92958@ns1.feral.com> <459E8AE7.90104@samsco.org> <20070105093930.Y34456@ns1.feral.com> <459E97E6.4000603@samsco.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Scott Long wrote: > mjacob@freebsd.org wrote: >> >> >> On Fri, 5 Jan 2007, Scott Long wrote: >> >>> mjacob@freebsd.org wrote: >>>> >>>> Opinions? Seems to do what *I* want for automatically attaching >>>> devices for mpt or isp when they appear on the fabric. All you have >>>> to do is >>>> alloc a ccb && a path and call xpt_rescan. >>> >>> Why do you need a separate thread for this? Many other drivers >>> already handle this just fine. >> >> In CAM? >> >> I did try doing it without a thread and had all sorts of problems that >> led to panics. I suppose I could try and fix that, but it's also true >> that notification that things have changed is almost certainly on an >> ithread and that the begin of a scan starts a heck of a lot of work >> before returning. >> >> D'ya think it's that crucial other than just another proc slot? >> >> -matt >> > > Ok, I see what you're saying. What I think needs to ultimately happen > is for the entire probe code to go into a thread. I've tried this a > couple of times, but have been caught up in trying to separate out the > SPI and non-SPI bits of it. Your patch is looks to be a good start at > the more simple approach. > > Scott > Oh, one more thing. Instead of it being a new XPT API function, could it be an async op with an appropriate handler in the XPT? Heck, maybe this is exactly how you 'fix' AC_FOUND_DEVICE to DTRT. Scott
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?459E989C.2020602>