From owner-freebsd-hackers Tue Oct 17 16:55:27 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id QAA14207 for hackers-outgoing; Tue, 17 Oct 1995 16:55:27 -0700 Received: from mail1.digital.com (mail1.digital.com [204.123.2.50]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id QAA14199 for ; Tue, 17 Oct 1995 16:55:25 -0700 Received: from muggsy.lkg.dec.com by mail1.digital.com; (5.65 EXP 4/12/95 for V3.2/1.0/WV) id AA10271; Tue, 17 Oct 1995 16:46:52 -0700 Received: from whydos.lkg.dec.com by muggsy.lkg.dec.com (5.65/DEC-Ultrix/4.3) with SMTP id AA16212; Tue, 17 Oct 1995 19:46:51 -0400 Received: from localhost (localhost [127.0.0.1]) by whydos.lkg.dec.com (8.6.11/8.6.9) with SMTP id TAA08488; Tue, 17 Oct 1995 19:47:45 GMT Message-Id: <199510171947.TAA08488@whydos.lkg.dec.com> X-Authentication-Warning: whydos.lkg.dec.com: Host localhost didn't use HELO protocol To: Bruce Evans Cc: hackers@freebsd.org Subject: Re: IPX now available In-Reply-To: Your message of "Tue, 17 Oct 1995 14:00:00 +1000." <199510170400.OAA23474@godzilla.zeta.org.au> X-Mailer: exmh version 1.5omega 10/6/94 Date: Tue, 17 Oct 1995 19:47:44 +0000 From: Matt Thomas Sender: owner-hackers@freebsd.org Precedence: bulk In <199510170400.OAA23474@godzilla.zeta.org.au> , you wrote: > >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. 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. I use a similar technique in the DC21x4x driver when autoprobing for the DC21041's media type. I use the general purpose timer register to cause interrupts at periodic intervals to test for status. The best thing is that system continues while the driver continues to sense the media. > 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. Desirable, yes. Required, no. > 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();'. If one adds threads, then that implies locking has been added or guarunteeing that will by invoked kernel services will not cause a scheduling event. 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? Matt Thomas Internet: matt@lkg.dec.com 3am Software Foundry WWW URL: Westford, MA Disclaimer: Digital disavows all knowledge of this message