Re: [PATCH 2.6.12.5 1/2] lib: allow idr to be used in irq context

[James Bottomley <James.Bottomley@SteelEye.com>]

On Sun, 2005-08-21 at 10:27 -0700, Luben Tuikov wrote:
> Is this the only use _you_ could find for a *radix tree*? ;-)
> Since of course sd.c uses it just as an enumeration, according to
> you this must be the only use? :-)

And Dicto Simpliciter to you too.

> It was designed as a general purpose id to pointer translation
> service, just as the comment in it says.

idr was specifically designed with unlocked pre-allocation in mind.  The
change you're proposing wants to allow pre allocation from irq context.
This really doesn't look like a good change because the whole point of
pre allocation is to do it at a point in time when the system can sleep
if it has to.

What I don't understand is why you need to pre allocate this tag from
irq context.  Best practise is to allocate when you have user context
but make use of it in IRQ context.

> > However, there is an infrastructure in the block layer called the
> > generic tag infrastructure which was designed precisely for this purpose
> > and which is designed to operate in IRQ context.
> 
> James, I'm sure you're well aware that,
>    - a request_queue is LU-bound,
>    - a SCSI _transport_ (*ANY*) can _only_ address domain devices, but
>      _not_ LUs.  LUs are *not* seen on the domain.
> 
> See the different associations?  Then why are you posting such emails?

So you're planning to do some type of tag command queueing outside of
the block framework?  Could you just look at what it would take to do it
within the existing framework first?  I seem to have wasted quite a bit
of time recently pulling spurious queueing code out of Adaptec drivers.

Remember that the code is adaptable ... we have non-block devices that
use block queues for instance.

James