Date: Mon, 15 Feb 2010 23:42:02 -0700 (MST) From: "M. Warner Losh" <imp@bsdimp.com> To: adrian.chadd@gmail.com Cc: freebsd-mips@FreeBSD.org Subject: Re: rspro board and mounting root from SD Message-ID: <20100215.234202.119882392285831214.imp@bsdimp.com> In-Reply-To: <d763ac661002152224i7310a0d3q52bd93b64428297a@mail.gmail.com> References: <d763ac661002042128g4eec226fue4011dc3195a86b@mail.gmail.com> <1265398292.2149.3.camel@brain.lan.terror.local> <d763ac661002152224i7310a0d3q52bd93b64428297a@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <d763ac661002152224i7310a0d3q52bd93b64428297a@mail.gmail.com>
Adrian Chadd <adrian.chadd@gmail.com> writes:
: Thanks, I'll just (ab)use this method of delaying the root mounting
: hackery until the umass child gets a chance to finishing probing.
:
: A "better" solution (eg enumerating which USB children need to finish
: probing and adding them in with relevant notification) may take a bit
: more hackery than I was hoping for. Maybe slicing something hackish
: into CAM would be evil but more generic..
There is something hackish already in CAM, sadly. kern.cam.boot_delay
looks like it defaults to '0' but you could set it to 4 I think to get
the same net-net as this patch.
I've talked through a bunch of solutions with Scott, and I think we
concluded that the right approach was for CAM to evolve a little.
As SIMs are discovered, they are added to a list of things to probe
(if their transport is polled, rather than self-discovered). Then,
after the interrupt hooks are done, it would run through the list
polling those SIMs. Once that's done, we'd release the hounds, errr,
I mean we'd allow mount_root to proceed.
Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100215.234202.119882392285831214.imp>