Date: Mon, 28 Sep 2009 22:49:23 +0200
From: Pavel Machek <pavel@ucw.cz>
To: Roland Dreier <rdreier@cisco.com>
Cc: linux-rdma@vger.kernel.org, linux-kernel@vger.kernel.org,
       general@lists.openfabrics.org, akpm@linux-foundation.org,
       torvalds@linux-foundation.org
Subject: Re: [ofa-general] Re: [GIT PULL] please pull ummunotify
Message-ID: <20090928204923.GA1960@elf.ucw.cz>
References: <aday6omhz9d.fsf@cisco.com> <20090915113434.GF1328@ucw.cz> <ada7hw0gsqz.fsf@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <ada7hw0gsqz.fsf@cisco.com>
User-Agent: Mutt/1.5.18 (2008-05-17)
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1213
Lines: 31

On Tue 2009-09-15 07:57:56, Roland Dreier wrote:
> 
>  > I don't remember seeing discussion of this on lkml. Yes it  is in
>  > -next...
> 
> eg http://lkml.org/lkml/2009/7/31/197 and followups, or search for v2
> and earlier patches.

Well... it seems little overspecialized. Just modifying libc to
provide hooks you want looks like better solution.

>  > Basically it allows app to 'trace itself'? ...with interesting mmap()
>  > interface, exporting int to userspace, hoping it behaves atomically...? 
> 
> Yes, it allows app to trace what the kernel does to memory mappings.  I
> don't believe there's any real issue to atomicity of mmap'ed memory,
> since userspace really just tests whether read value is == to old read
> value or not.

That still needs memory barriers etc.. to ensure reliable operation,
no?
									Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
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/