From owner-freebsd-hackers  Mon Oct 16 21:03:17 1995
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.6.12/8.6.6) id VAA08352
          for hackers-outgoing; Mon, 16 Oct 1995 21:03:17 -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 VAA08344
          for <hackers@freebsd.org>; Mon, 16 Oct 1995 21:03:09 -0700
Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id OAA23474; Tue, 17 Oct 1995 14:00:00 +1000
Date: Tue, 17 Oct 1995 14:00:00 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199510170400.OAA23474@godzilla.zeta.org.au>
To: bde@zeta.org.au, matt@lkg.dec.com
Subject: Re: IPX now available
Cc: hackers@freebsd.org, se@zpr.uni-koeln.de
Sender: owner-hackers@freebsd.org
Precedence: bulk

>> Device drivers will
>> need to be able to sleep in their probe and attach routines for other
>> reasons.  When tsleep() at probe and attach time is implemented,
>> complicated time-dependent orderings (aka races :-) will be easy to
>> implemented - just sleep until the modules that you depend on are
>> loaded.

>It depends on when drivers will be probed but if we assume it's before
>the process initialization, then this begs for kernel threads.  While
>highly desirable, I think kernel threads would be overkill if added
>just for this.  Instead, use of timeout() and proper sync points would
>achieve the same capability at far less implementation cost.

timeout() is no use if there is nothing to give up control to.  I think
some sort of threading is required, and I want something that has the
same interface for drivers that are probed early and ones that are
probed after the system is running normally.  tsleep() is good enough
for the latter case and its interface is probably be good enough for
early use.  tsleep() itself could do something like
`if (cold) next_mini_thread(); else normal_stuff();'.

Br4uce