From owner-freebsd-arch@FreeBSD.ORG Sat Nov 24 19:51:02 2012 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A1196A4C; Sat, 24 Nov 2012 19:51:02 +0000 (UTC) (envelope-from bright@mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 7E1B18FC13; Sat, 24 Nov 2012 19:51:02 +0000 (UTC) Received: from Alfreds-MacBook-Pro-5.local (c-67-180-208-218.hsd1.ca.comcast.net [67.180.208.218]) by elvis.mu.org (Postfix) with ESMTPSA id 18A2C1A3C6A; Sat, 24 Nov 2012 11:50:56 -0800 (PST) Message-ID: <50B12520.7040508@mu.org> Date: Sat, 24 Nov 2012 11:50:56 -0800 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Mark Linimon Subject: Re: [RFC] sema_wait_sig References: <20121124193010.GB1627@lonesome.com> In-Reply-To: <20121124193010.GB1627@lonesome.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: attilio@FreeBSD.org, arch@freebsd.org, Oleksandr Tymoshenko X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Nov 2012 19:51:02 -0000 On 11/24/12 11:30 AM, Mark Linimon wrote: > Alfred Perlstein wrote: >> According to this post I shouldn't touch anything that has to do with any >> SMP stuff until you complete your upcoming work because it will all be >> turned upside down. >> >> This is not what people should think about FreeBSD, it will drive >> developers away. >> >> Heck, I'm scared now to even write anything. >> >> -Alfred > Logical fallacy is fallacious. > > I've seen several people jump from "I'm getting pushback on foo" to > "nothing at all can be done" recently. It's bogus reasoning. > > My view is that the project is no longer in its infancy, where quick > and sometimes arbitrary changes could be made. That may have scaled > early on -- but now we have hundreds of developers, thousands of > contributors, and bazillions of users. Now we need consensus and buy-in > and roadmaps. > > Next, rather than compare who has done how much hard work and when > (and you both have), Attilio has been doing a lot of work on locking > over the past few years. If he (and possibly the people who have been > looking over his shoulder) have a view on how we should move forward, > I think they have earned the right to state it. > > Finally, IMHO, hyperbole can turn off developers too. > No offense to Attilio, the work, debugging, optimizations he's done have been beyond invaluable. Attilio's work on performance and reliability has been very helpful to me and many others. However, as someone who now is going to base kernel work on FreeBSD I find this change-for-the-sake-of-change to be completely terrifying. Well let's reiterate the content of Attilio's message: 1. lockmgr will be replaced/rototilled by something. 2. sema will be replaced/rototilled by something. 3. sleep mutexes and spin mutex will have API rototilled by something into something else. Why? So basically in the near future all locking primitives will change. Not based on feature parity with other OS, not based on preserving KPI. Just because it's "unclean". Lockmgr has been a ... "pain" forever, it should go or at least never ever be used by anything but VFS. But back to the point, this isn't a roadmap, this is churn for the sake of churn. For aesthetics. It's not right and you know it. Please look at how the inifiband stuff was managed finally, by basically shimming up a Linux compat layer to get that working. Have a look at how zfs works, but providing a stable API. -Alfred