Subject: Re: interleaved disk probing output
To: Bill Studenmund <wrstuden@netbsd.org>
From: Manuel Bouyer <bouyer@antioche.eu.org>
List: tech-kern
Date: 10/13/2003 20:11:50
On Mon, Oct 13, 2003 at 10:00:01AM -0700, Bill Studenmund wrote:
> > The atabus thread covers everything attached to the atabus (that is,
> > wd and low level requests from atapibus).
> > The atapibus thread covers what's attached to the atapibus, for high-level
> > functionalities.
> 
> As long as the atapibus operations happen within a thread context, does it 
> matter if it's the "atapi" or "ata" thread?

It can, both layers would have to cooperate to share the thread (
make sure we don't tlseep in atapi if ata needs the thread). This would
add some complexity and can lead to deadlock.

> 
> > I've been thinking of ways to have a single thread handle boths. The problem
> > is that we can have atapibus without atabus, or atabus without atapibus (and
> > atapibus can attach to something else than atabus).
> 
> I think the solution to that is that you require whatever ataches an atapi 
> bus do so within a thread context. Take the atapi bus thread creation code 
> out of atapi code, and put it in the atachers that don't already have a 
> thread per device.
> 
> You already must have some sort of API that the ata bus exports to the 
> atapibus, so just extend it to include the (implicit) presence of a 
> thread.

The problem is that the thread code is shared with scsi (there's nothing
atapi-specific here). We could require scsi to also provide a thread (some
scsi HBA drivers already have their own thread), but we would then have added
complexity in both layers to make them cooperate (scsipi may want to tlseep
when the low-level driver wants the thread to perform what would
awake the upper-level thread). This may require some major changes to scsipi,
and we may use more resources instead of less.

I think this should be solved in the way matt proposed some time ago,
and not with ad-hoc interfaces between layers. A tsleep() in kernel
thread context would not do what it actually does, but returns the thread to
a poll so that it can be used somewhere else.

-- 
Manuel Bouyer <bouyer@antioche.eu.org>
     NetBSD: 24 ans d'experience feront toujours la difference
--