From owner-freebsd-mobile  Fri Oct 24 09:38:24 1997
Return-Path: <owner-freebsd-mobile>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id JAA02379
          for mobile-outgoing; Fri, 24 Oct 1997 09:38:24 -0700 (PDT)
          (envelope-from owner-freebsd-mobile)
Received: from word.smith.net.au (ppp20.portal.net.au [202.12.71.120])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA02367
          for <mobile@freebsd.org>; Fri, 24 Oct 1997 09:38:06 -0700 (PDT)
          (envelope-from mike@word.smith.net.au)
Received: from word.smith.net.au (localhost [127.0.0.1])
	by word.smith.net.au (8.8.7/8.8.5) with ESMTP id CAA01177;
	Sat, 25 Oct 1997 02:04:28 +0930 (CST)
Message-Id: <199710241634.CAA01177@word.smith.net.au>
X-Mailer: exmh version 2.0zeta 7/24/97
To: Nate Williams <nate@mt.sri.com>
cc: mobile@freebsd.org
Subject: Re: Patches from -current for -stable I'd like to commit after testing 
In-reply-to: Your message of "Fri, 24 Oct 1997 10:06:37 CST."
             <199710241606.KAA20591@rocky.mt.sri.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Sat, 25 Oct 1997 02:04:25 +0930
From: Mike Smith <mike@smith.net.au>
Sender: owner-freebsd-mobile@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

> > > 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.

Let's just make sure I understand what the 'mini-probe' entails, as I 
may be misunderstanding this.

Before the mini-probe runs, is the device detached?  ie. the mini-probe 
is basically going to run the probe and then attach routines again?
(Do you have to do this anyway, to get the PCCARD back to a known 
state?)

> 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'.

I understand all about that; I've always wanted to be able to stuff the 
card recognition data (or some subset therof) into the kernel.

mike