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 - : send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
