From: Linus Torvalds <torvalds@transmeta.com> To: Martin Dalecki <dalecki@evision-ventures.com> Subject: Re: [PATCH] 2.5.15 IDE 62 Date: Mon, 13 May 2002 09:54:02 -0700 (PDT) Cc: Jens Axboe <axboe@suse.de>, Kernel Mailing List <linux-kernel@vger.kernel.org> [ Martin - just a heads up that I'm not applying 62, so don't make new IDE patches relative to that ] On Mon, 13 May 2002, Martin Dalecki wrote: > > Well on the channel level they are safe modulo cmd640 and rz1000. > We can handle them by serializing them on the global lock > in do_ide_request. Like: > > if (ch->drive[0].serialized|| ch->drive[1].serialized) > then > spin_lock(serialize_lock); NO. The whole point of having a per-queue lock pointer is that this should be initialized at queue creation time. Don't add more crud to the IDE locking, we want to get _rid_ of the locking that IDE has thought (traditionally incorrectly) that it could do better than the higher levels. So when you create the queue, you should decide at THAT point whether you just want to pass in the same lock or not. For a cmd640, you make sure that both queues get created with the same lock. And for non-broken chipsets, you use per-queue locks. And then you make sure that nobody EVER uses any other lock than the queue lock. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/