Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 17 Oct 1995 19:47:44 +0000
From:      Matt Thomas <matt@lkg.dec.com>
To:        Bruce Evans <bde@zeta.org.au>
Cc:        hackers@freebsd.org
Subject:   Re: IPX now available 
Message-ID:  <199510171947.TAA08488@whydos.lkg.dec.com>
In-Reply-To: Your message of "Tue, 17 Oct 1995 14:00:00 %2B1000." <199510170400.OAA23474@godzilla.zeta.org.au> 

next in thread | previous in thread | raw e-mail | index | archive | help

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:    <currently homeless>
Westford, MA              Disclaimer: Digital disavows all knowledge
                                      of this message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199510171947.TAA08488>