Subject: Re: [PATCH] synclink_gt add gpio feature
From: Paul Fulghum <paulkf@microgate.com>
To: Andrew Morton <akpm@osdl.org>
Cc: linux-kernel@vger.kernel.org
In-Reply-To: <20060324161350.0a18c29b.akpm@osdl.org>
References: <1143216251.8513.3.camel@amdx2.microgate.com>
	 <20060324141929.1fff0c15.akpm@osdl.org> <44247812.1040301@microgate.com>
	 <20060324151245.299ff2c1.akpm@osdl.org>
	 <1143244969.2594.24.camel@localhost.localdomain>
	 <20060324161350.0a18c29b.akpm@osdl.org>
Content-Type: text/plain
Date: Fri, 24 Mar 2006 19:52:18 -0600
Message-Id: <1143251538.2594.46.camel@localhost.localdomain>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1071
Lines: 31

On Fri, 2006-03-24 at 16:13 -0800, Andrew Morton wrote:
> It should be possible to communicate between waker and waiter via
> __wait_queue.private and __wait_queue.func.  Make ->private point at some
> on-stack thing, let the waker read and write that.
> 
> That'd involve some rather low-level poking at waitqueues, but I don't
> expect those facilities are going away.

__wait_queue.private already holds a
pointer to the task structure of the waiting process

I might be able to implement what I need in a way
that more closely resembles how wait_on_bit extends
the standard wait queue. But the result is the same:
a new wrapper (new structure containing wait_queue_t
and access/init functions) built on top of the
existing wait queue.

I'll revisit this tomorrow to make sure I'm
thinking about this correctly.

--
Paul


-
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/