From owner-freebsd-hackers  Tue Oct 17 23:19:59 1995
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.6.12/8.6.6) id XAA29811
          for hackers-outgoing; Tue, 17 Oct 1995 23:19:59 -0700
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19])
          by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id XAA29797
          for <hackers@freebsd.org>; Tue, 17 Oct 1995 23:18:45 -0700
Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id QAA14202; Wed, 18 Oct 1995 16:15:53 +1000
Date: Wed, 18 Oct 1995 16:15:53 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199510180615.QAA14202@godzilla.zeta.org.au>
To: bde@zeta.org.au, matt@lkg.dec.com
Subject: Re: IPX now available
Cc: hackers@freebsd.org
Sender: owner-hackers@freebsd.org
Precedence: bulk

>> timeout() is no use if there is nothing to give up control to.

>Control will return back to the caller of probe (or attach or ...).
>probe could return a meaningful status like EINPROGRESS which would
>tell the caller that the probe in continuing.  Eventually the driver
>(via timeout) will call probe_done() to say the probe finished.

For some reason I forgot about you mentioning timeouts and thought you
meant something more formal involving lots of driver probe/attach states
and entry points in each driver to handle state transitions.  This
might be good for forcing you to think about synchronization but it
would involve modifying too many drivers to begin with.

>Let me say upfront that I would love to have kernel threads.  But
>I'm wary that you are underestinating the amount of work needed to
>add them.  Properly done kernel thread services are probably the
>most significant and useful addition that can be made to FreeBSD.
>Can you say SMP?  Real pthread support?  Better real time support
>by thread preemption?  

I only want toy threads (at first) to allow a common interface in
drivers that are called early.  You're probably right that I'm
underestimating the difficulties.  I want interrupts to work normally
after they are attached, and few or no probe/attach routines are
prepared for interrupts.

Bruce