On 08/22/05 10:28, James Bottomley wrote: > On Sun, 2005-08-21 at 20:52 -0700, Andrew Morton wrote: > >>erp. posix_timers has its own irq-safe lock, so we're doing extra, >>unneeded locking in that code path. > > > Possibly, the posix timer code is rather convoluted in this area so I'm > not entirely sure my analysis is correct. Then _please_ drop this thread. >>I think providing locking inside idr.c was always a mistake - generally we >>rely on caller-provided locking for such things. > > > Well, the reason is because they wanted lockless pre-alloc. If you do > it locked, you can't use GFP_KERNEL for the memory allocation flag which > rather defeats its purpose. James, please drop this thread and let's concentrate on SCSI. > Perhaps the bug is in the API. We have pre-allocate, new, find and > remove. Perhaps what we're missing is a reuse all of which could then > rely on caller provided locking, with pre-alloc and remove requiring > user context but new, find and reuse being happy in irq context. No, the bug is _not_ in the API. *IDR is perfect as it is.* It gives the caller a lot of freedom, without internal restrictions (other than the provided by this patch). Now please let's go back to SCSI and leave other people's code and API alone. Shall we James? SCSI Core needs enough work to have SCSI people worry about other people's code and design... or is this the modus operandi of the SCSI Core maintainer...? "Documentation/ManagementStyle", please? Thank you, Luben - : 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
