Date: Fri, 24 Oct 1997 10:06:37 -0600 (MDT) From: Nate Williams <nate@mt.sri.com> To: Mike Smith <mike@smith.net.au> Cc: Nate Williams <nate@mt.sri.com>, mobile@freebsd.org Subject: Re: Patches from -current for -stable I'd like to commit after testing Message-ID: <199710241606.KAA20591@rocky.mt.sri.com> In-Reply-To: <199710241558.BAA00950@word.smith.net.au> References: <199710241552.JAA20521@rocky.mt.sri.com> <199710241558.BAA00950@word.smith.net.au>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > > True, but if you could do a mini-probe (as the current code attempts to > > > > do), then it should work. However, somehow things aren't yet 'enough' > > > > alive when we call the mini-probe, so it doesn't work. > > > > > > Um, "mini-probe"? ie. "is what used to be there still there?" > > > > Yep. epinit(slot, int), where the int says 'is this the first time for > > this device'. If the second parameter is 0, then it does a > > 'mini-probe'. > > Not good enough. I take one card out and replace with a > similar-but-different one (eg. two 3c589's, two NE2000's, etc.) The > miniprobe will say "yes, it's the same", even though it's not. But, it will work the same, since we don't program the card to do anything, just the controller. If two 'fairly identical' cards can be probed the same, they also better act the same given the same conditions. I think this is a non-issue. > > > > This is what the code that's enabled by apm_pccard_resume does (sort > > > > of). Except that it fakes both remove/insertion at resume time. The > > > > bad thing is that it requires that the pccard daemon be running for the > > > > 'insertion' to be correctly done. > > > > > > Natch; it has to rummage the database somehow. How else would you get > > > at this information? > > > > It's already all saved in the kernel now from when the card was > > initially inserted. > > Only if the miniprobe succeeds. If it fails, you still need pccardd to > handle a possible new device. I appreciate that the miniprobe is meant > as a speed optimisation; I'm just not sure it's robust enough. I think it is. What I'd like to do is be able to move some of the configuration into the kernel, so we can *rely* on certain things being there for embedded applications. For example, if I have a machine that is tight on memory, I want pccardd to run until it gets both cards configured, and then die to free up memory. You may ask why this is important, and who would ever do something that silly, and I'll answer 'because it is'. Nate
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199710241606.KAA20591>