From owner-freebsd-arch@FreeBSD.ORG Tue Oct 28 16:21:06 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 12C0632B for ; Tue, 28 Oct 2014 16:21:06 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DFBC220E for ; Tue, 28 Oct 2014 16:21:05 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 32B78B980; Tue, 28 Oct 2014 12:21:04 -0400 (EDT) From: John Baldwin To: Konstantin Belousov Subject: Re: RfC: fueword(9) and casueword(9) Date: Tue, 28 Oct 2014 11:46:49 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20140415; KDE/4.5.5; amd64; ; ) References: <20141021094539.GA1877@kib.kiev.ua> <2048849.GkvWliFbyg@ralph.baldwin.cx> <20141027165557.GC1877@kib.kiev.ua> In-Reply-To: <20141027165557.GC1877@kib.kiev.ua> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201410281146.49370.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 28 Oct 2014 12:21:04 -0400 (EDT) Cc: freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 16:21:06 -0000 On Monday, October 27, 2014 12:55:57 pm Konstantin Belousov wrote: > On Mon, Oct 27, 2014 at 11:17:51AM -0400, John Baldwin wrote: > > On Tuesday, October 21, 2014 07:23:06 PM Konstantin Belousov wrote: > > > On Wed, Oct 22, 2014 at 01:41:12AM +1100, Bruce Evans wrote: > > > > A new API should try to fix these __DEVOLATILE() abominations. I think it > > > > is safe, and even correct, to declare the pointers as volatile const void > > > > *, since the functions really can handle volatile data, unlike copyin(). > > > > > > > > Atomic op functions are declared as taking pointers to volatile for > > > > similar reasons. Often they are applied to non-volatile data, but > > > > adding a qualifier is type-safe and doesn't cost efficiency since the > > > > pointer access is is not known to the compiler. (The last point is not > > > > so clear -- the compiler can see things in the functions since they are > > > > inline asm. fueword() isn't inline so its (in)efficiency is not changed.) > > > > > > > > The atomic read functions are not declared as taking pointers to const. > > > > The __DECONST() abomination might be used to work around this bug. > > > > > > I prefer to not complicate the fetch(9) KPI due to the mistakes in the > > > umtx structures definitions. I think that it is bug to mark the lock > > > words with volatile. I want the fueword(9) interface to be as much > > > similar to fuword(9), in particular, volatile seems to be not needed. > > > > I agree with Bruce here. casuword() already accepts volatile. I also > > think umtx is correct in marking the field as volatile. They are subject > > to change without the compiler's knowledge albeit by other threads > > rather than signal handlers. Having them marked volatile doesn't really > > matter for the kernel, but the header is also used in userland and is > > relevant in sem_new.c, etc. > > You agree with making fueword() accept volatile const void * as the > address ? Or do you agree with the existence of the volatile type > qualifier for the lock field of umtx structures ? I agree with both (I thought Bruce only asserted the first). > I definitely do not want to make fueword() different from fuword() in > this aspect. If changing both fueword() and fuword() to take volatile > const * address, this should be different patch. I also agree that fuword() and fueword() should take identical arguments, so if this change is made it should be a separate patch (and should include suword()). -- John Baldwin