> On Wed, Sep 05, 2001 at 03:20:33PM -0700, Matthew Jacob wrote:
>
>  > How invasive would it be to add/require a per-CPU
>  > servicing_interrupt() call to all the ports?
>  > Or perhaps safe_to_sleep()?
>
> Actually, it seems to me that if you have to make this kind of
> decision, there's a more fundamental problem.

Why?

>
> Can you point me at the code path in question?

It's the isp driver- it would very much *like* to use tsleep when called from
the isp fibre channel state recover thread for mailbox commands.

The basic design here is that the QLogic mailbox commands are synchronous to
code flow- after all, they aren't really command oriented. They're mostly for
doing things like saying "Set target parameters" or "Perform Fabric Login"-
these are synchronous steps that it's just a lot better to wait until they're
done.

Rather than poll, it's better if you can do some kind of pause execution until
done. So- it's nice to sleep if you can. There's a cleanup thread that at
least doesn't make some random user process pay the penalty of sleeping for
the rather large Fibre Channel goop that has to be done.

And, yes, I've considered rewriting this to be more interrupt driven too- but
this still doesn't get away from what should be a very basic question that any
piece of kernel code should be able to ask:

	"Can I call tsleep now or not?"

If you cannot ask that question from any piece of code, then you have to make
assumptions about caller state, which seems to be me far more odious than
asking the question.

If you can't ask the question and you can't infer caller state, then there
shouldn't be any tsleep at all and NetBSD/*BSD/Unix should be more like Thoth
or Auspex' m16 where all threads of execution, once activated, run to
completion (no interrupts, no pausing halfway down the stack). But that isn't
this system.


>  Seems like there's
> a better way (using either *only* tsleep, or *only* some callback
> mechanism...)

No, I don't agree. See above.

-matt