From: "Adam J. Richter" <adam@yggdrasil.com>
Date: Tue, 30 Jul 2002 13:10:47 -0700
Message-Id: <200207302010.NAA04198@baldur.yggdrasil.com>
To: martin@dalecki.de
Subject: Re: cli/sti removal from linux-2.5.29/drivers/ide?
Cc: linux-kernel@vger.kernel.org
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1755
Lines: 39

Martin Dalecki wrote:
>Adam J. Richter wrote:

>> 	That said, I think all the "lock group" logic in drivers/ide
>> may be useless, and it would be pretty straightforward to delete all
>> that code, have ata_channel->lock be a lock rather than a pointer to one,
>> and have it be initialized before that first call to ch->tuneproc, in
>> which case we could just have interrupts off and ch->lock held in all
>> cases when ch->tuneproc is called.  I did not want to do this in my patch,
>> because I wanted to keep my patch as small as possible, but perhaps it
>> would be worth doing now just to simplify the rules for calling ch->tuneproc.

>Not quite. It's not that easy becouse the same lock is used by the BIO
>layer to synchronize between for example master and slave devices.

	Master and slave devices share the same channel, so

		master->channel		== slave->channel
		&master->channel->lock	== &slave->channel->lock

	So their queue->lock pointer would continue to point to
the same lock: &channel->lock.

>There are other problems with this but right now you can hardly do 
>something about it.

	I'd be intersted in knowing what one of those other problems
is.  Otherwise, I don't understand why I can't eliminate the "lock
group" stuff.

Adam J. Richter     __     ______________   575 Oroville Road
adam@yggdrasil.com     \ /                  Milpitas, California 95035
+1 408 309-6081         | g g d r a s i l   United States of America
                         "Free Software For The Rest Of Us."
-
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/