On Wed, 5 Sep 2001, Jason R Thorpe wrote:

> On Thu, Sep 06, 2001 at 12:14:19PM +0930, Greg Lehey wrote:
> 
>  > All else being equal, given the choice between a variable or a
>  > function, I'd use the variable any day.
> 
> I'd rather restructure the entire code path so the test is
> never necessary :-)

Then we need to implement ithreads as Solaris implements them- so you *can*
call tsleep from hardware interrupt level- and as FreeBSD supposedly gropes
toward.

I'm pretty convinced that lacking such freedom, knowing whether it is safe to
call tsleep is functionality worth having. The implementation need not be
hacky, and could, in fact, be SMP aware. After all, it's per processor data
(in some systems, at least) as to whether you're running a context where it is
safe to sleep && be (re)schedulable. Despite what Bill says, it need not be a
costly test- but this is why I asked whether it would be invasive. The answer
I get is "Yes" and the implied (from Jason) "You need to rewrite your driver"-
which is somewhat annoying.

Frankly, the alternative is a less functional system. But you know- I *really*
don't need to argue this at all. I think it would be useful. If others don't
see that- that's fine too.

If there's one thing I've learned over the last year with the *BSDs is that
losing sleep over these things isn't worth it. I think such functionality as I
suggest would make *my* job easier- in providing fibre channel fabric support
for the *BSDs- but such things I'm sure are really not all that important and
are not relevant to where *MY* paying work comes from (which is from Solaris,
where this isn't a problem, and Linux, where there are too many other things
to worry about).

So- hey- no problemo! I asked- and I think pretty much the consensus is:

	"No- this is not a problem that needs fixing".

I've partially worked around it in the isp(4) driver for now.

-matt