From owner-freebsd-arch@FreeBSD.ORG Mon Nov 19 08:09:43 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B0AA8FF8; Mon, 19 Nov 2012 08:09:43 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 6344C8FC08; Mon, 19 Nov 2012 08:09:43 +0000 (UTC) Received: from critter.freebsd.dk (unknown [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 321EA8A3FC; Mon, 19 Nov 2012 08:09:42 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.5/8.14.5) with ESMTP id qAJ89f4u031882; Mon, 19 Nov 2012 08:09:41 GMT (envelope-from phk@phk.freebsd.dk) To: Marcel Moolenaar Subject: Re: [RFC] test layout/standardization for FreeBSD In-reply-to: From: "Poul-Henning Kamp" References: <7099.1352886181@critter.freebsd.dk> Date: Mon, 19 Nov 2012 08:09:41 +0000 Message-ID: <31881.1353312581@critter.freebsd.dk> Cc: Garrett Cooper , George Neville-Neil , "freebsd-arch@FreeBSD.org Arch" , Matthew Fleming 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: Mon, 19 Nov 2012 08:09:43 -0000 -------- In message , Marcel Moolenaar writes: >For example: If a test is not reliable on a heavily loaded machine, >then the test is ipso facto not 100% deterministic. So, B implies >A. How is this different from a meta data perspective? If we test >a RNG, are we ever going to be 100% deterministic? Some tests are not 100% deterministic no matter what. That is an important distinction. >Also, the estimated duration for tests is very platform specific. Only if CPU or I/O bound. Tests for things like dynamic route-expiry, and other timeout driven parts of the system will have long realtime clock, but short cpu-clock. For a comprehensive nightly test-run, you want such test-cases, for a quick sanitycheck on your kernel rewrite, you probably don't. I fully agree with your "crawl before we run" approach, but testing is a quite mature, if underappreciated, discipline, and we would do well to learn from others mistakes. All I'm asking at this point, is that we make a space for storing this metadata in a machine-readable format. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Mon Nov 19 16:16:53 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4E985572; Mon, 19 Nov 2012 16:16:53 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by mx1.freebsd.org (Postfix) with ESMTP id 15B848FC12; Mon, 19 Nov 2012 16:16:48 +0000 (UTC) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKUKpbaU8BAqCB3zW+QQ0+qyrFb39g7s+2@postini.com; Mon, 19 Nov 2012 08:16:52 PST Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB01-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 19 Nov 2012 08:13:34 -0800 Received: from chaos.jnpr.net (chaos.jnpr.net [172.24.29.229]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id qAJGDX328225; Mon, 19 Nov 2012 08:13:33 -0800 (PST) (envelope-from sjg@juniper.net) Received: from chaos.jnpr.net (localhost [127.0.0.1]) by chaos.jnpr.net (Postfix) with ESMTP id 6A37C58094; Mon, 19 Nov 2012 08:13:33 -0800 (PST) To: Poul-Henning Kamp Subject: Re: [RFC] test layout/standardization for FreeBSD In-Reply-To: <31881.1353312581@critter.freebsd.dk> References: <7099.1352886181@critter.freebsd.dk> <31881.1353312581@critter.freebsd.dk> Comments: In-reply-to: "Poul-Henning Kamp" message dated "Mon, 19 Nov 2012 08:09:41 +0000." From: "Simon J. Gerraty" X-Mailer: MH-E 7.82+cvs; nmh 1.3; GNU Emacs 22.3.1 Date: Mon, 19 Nov 2012 08:13:33 -0800 Message-ID: <20121119161333.6A37C58094@chaos.jnpr.net> MIME-Version: 1.0 Content-Type: text/plain Cc: Garrett Cooper , George Neville-Neil , "freebsd-arch@FreeBSD.org Arch" , Matthew Fleming , Marcel Moolenaar 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: Mon, 19 Nov 2012 16:16:53 -0000 On Mon, 19 Nov 2012 08:09:41 +0000, "Poul-Henning Kamp" writes: >Some tests are not 100% deterministic no matter what. That is >an important distinction. Yes. It would probably be worth defining some meta tags to identify things like that. Even if the outcome were nothing more than a warning to the user "hey the results here can vary - don't panic" Still, to me, tests of that nature start to sound more like system tests than unit-tests. >>Also, the estimated duration for tests is very platform specific. > >Only if CPU or I/O bound. Tests for things like dynamic route-expiry, >and other timeout driven parts of the system will have long realtime >clock, but short cpu-clock. Again, that sounds more like a system test than unit-test. For a unit-test you would want to mock the environment so that your timer events or whatever are fully controlled (and compressed). >I fully agree with your "crawl before we run" approach, but testing >is a quite mature, if underappreciated, discipline, and we would do >well to learn from others mistakes. Agreed. One of the common misstakes it seems is bluring the boundaries between unit, function and system tests. System tests are needed for sure, but simple unit-tests (of the bits that can be simply unit-tested) are far more valuable for establishing good overal test coverage. >All I'm asking at this point, is that we make a space for storing >this metadata in a machine-readable format. Sounds reasonable, though exactly what and how, is to be determined, and my hope is that such info should not be needed until we start pushing unit-tests into system test territory. Thanks --sjg From owner-freebsd-arch@FreeBSD.ORG Mon Nov 19 17:24:04 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 30B7DC01; Mon, 19 Nov 2012 17:24:04 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id A5C408FC12; Mon, 19 Nov 2012 17:24:03 +0000 (UTC) Received: from critter.freebsd.dk (unknown [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id B729A8A3FC; Mon, 19 Nov 2012 17:23:55 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.5/8.14.5) with ESMTP id qAJHNs64005715; Mon, 19 Nov 2012 17:23:54 GMT (envelope-from phk@phk.freebsd.dk) To: "Simon J. Gerraty" Subject: Re: [RFC] test layout/standardization for FreeBSD In-reply-to: <20121119161333.6A37C58094@chaos.jnpr.net> From: "Poul-Henning Kamp" References: <7099.1352886181@critter.freebsd.dk> <31881.1353312581@critter.freebsd.dk> <20121119161333.6A37C58094@chaos.jnpr.net> Date: Mon, 19 Nov 2012 17:23:54 +0000 Message-ID: <5714.1353345834@critter.freebsd.dk> Cc: Garrett Cooper , George Neville-Neil , Marcel Moolenaar , Matthew Fleming , "freebsd-arch@FreeBSD.org Arch" 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: Mon, 19 Nov 2012 17:24:04 -0000 -------- In message <20121119161333.6A37C58094@chaos.jnpr.net>, "Simon J. Gerraty" write s: >Agreed. One of the common misstakes it seems is bluring the boundaries >between unit, function and system tests. Well, good luck with upholding that distinction on any piece of non-trivial software. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Mon Nov 19 18:48:40 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 49F70EB4; Mon, 19 Nov 2012 18:48:40 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by mx1.freebsd.org (Postfix) with ESMTP id 5FCD98FC0C; Mon, 19 Nov 2012 18:48:36 +0000 (UTC) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKUKp/A2lHjc+9M1WLH3tAOUEB9CVppyBM@postini.com; Mon, 19 Nov 2012 10:48:39 PST Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB01-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 19 Nov 2012 10:47:41 -0800 Received: from chaos.jnpr.net (chaos.jnpr.net [172.24.29.229]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id qAJIle345000; Mon, 19 Nov 2012 10:47:40 -0800 (PST) (envelope-from sjg@juniper.net) Received: from chaos.jnpr.net (localhost [127.0.0.1]) by chaos.jnpr.net (Postfix) with ESMTP id 2D07958094; Mon, 19 Nov 2012 10:47:40 -0800 (PST) To: Poul-Henning Kamp Subject: Re: [RFC] test layout/standardization for FreeBSD In-Reply-To: <5714.1353345834@critter.freebsd.dk> References: <7099.1352886181@critter.freebsd.dk> <31881.1353312581@critter.freebsd.dk> <20121119161333.6A37C58094@chaos.jnpr.net> <5714.1353345834@critter.freebsd.dk> Comments: In-reply-to: "Poul-Henning Kamp" message dated "Mon, 19 Nov 2012 17:23:54 +0000." From: "Simon J. Gerraty" X-Mailer: MH-E 7.82+cvs; nmh 1.3; GNU Emacs 22.3.1 Date: Mon, 19 Nov 2012 10:47:40 -0800 Message-ID: <20121119184740.2D07958094@chaos.jnpr.net> MIME-Version: 1.0 Content-Type: text/plain Cc: Garrett Cooper , George Neville-Neil , Marcel Moolenaar , Matthew Fleming , "freebsd-arch@FreeBSD.org Arch" 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: Mon, 19 Nov 2012 18:48:40 -0000 On Mon, 19 Nov 2012 17:23:54 +0000, "Poul-Henning Kamp" writes: >Well, good luck with upholding that distinction on any piece of >non-trivial software. Oh sorry if it sounded like I was refering to you, we have a huge investment in system testing which many people keep calling unit-tests, which then confuses people when they hear we should do more/better unit-testing. System testing is an expensive way to find bugs. From owner-freebsd-arch@FreeBSD.ORG Fri Nov 23 06:12:29 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 E6E03DBC for ; Fri, 23 Nov 2012 06:12:29 +0000 (UTC) (envelope-from gonzo@id.bluezbox.com) Received: from id.bluezbox.com (id.bluezbox.com [88.198.91.248]) by mx1.freebsd.org (Postfix) with ESMTP id 8F2A58FC0C for ; Fri, 23 Nov 2012 06:12:29 +0000 (UTC) Received: from [207.6.254.8] (helo=[192.168.1.67]) by id.bluezbox.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1TbmUu-000D14-BC for arch@freebsd.org; Thu, 22 Nov 2012 22:12:22 -0800 From: Oleksandr Tymoshenko Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [RFC] sema_wait_sig Message-Id: Date: Thu, 22 Nov 2012 22:12:02 -0800 To: arch@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Sender: gonzo@id.bluezbox.com X-Spam-Level: -- X-Spam-Report: Spam detection software, running on the system "id.bluezbox.com", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: Hello, Is there any particular reason FreeBSD does not have sema_wait_sig function? It seems to be easily implementable using cv_wait_sig function. The reason I'm asking is that I'm getting some Linux drivers ported to FreeBSD and the code in question relies on semaphores and there is no obvious alternative to down_interruptible function. I realize that not all approaches to driver development are easily mappable from OS to OS but in this case lack of cv_wait_sig seems like gap in API. Unless of course there is strong rationale behind it. [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] 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: Fri, 23 Nov 2012 06:12:30 -0000 Hello, Is there any particular reason FreeBSD does not have sema_wait_sig function? It seems to be easily implementable using cv_wait_sig function. The reason I'm asking is that I'm getting some Linux drivers ported to FreeBSD and the code in question relies on semaphores and there is no obvious alternative to down_interruptible function. I realize that not all approaches to driver development are easily mappable from OS to OS but in this case lack of cv_wait_sig seems like gap in API. Unless of course there is strong rationale behind it. Thank you From owner-freebsd-arch@FreeBSD.ORG Fri Nov 23 19:17:13 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 CA5F6805 for ; Fri, 23 Nov 2012 19:17:13 +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 ACF988FC12 for ; Fri, 23 Nov 2012 19:17:13 +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 101C81A3D5B; Fri, 23 Nov 2012 11:17:07 -0800 (PST) Message-ID: <50AFCBB3.9060708@mu.org> Date: Fri, 23 Nov 2012 11:17:07 -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: Oleksandr Tymoshenko Subject: Re: [RFC] sema_wait_sig References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: arch@freebsd.org 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: Fri, 23 Nov 2012 19:17:13 -0000 On 11/22/12 10:12 PM, Oleksandr Tymoshenko wrote: > Hello, > > Is there any particular reason FreeBSD does not have sema_wait_sig > function? It seems to be easily implementable using cv_wait_sig > function. > > The reason I'm asking is that I'm getting some Linux drivers > ported to FreeBSD and the code in question relies on semaphores > and there is no obvious alternative to down_interruptible function. > I realize that not all approaches to driver development are easily > mappable from OS to OS but in this case lack of cv_wait_sig seems > like gap in API. Unless of course there is strong rationale behind it. > Sounds like just an oversight. Go for it! -Alfred From owner-freebsd-arch@FreeBSD.ORG Fri Nov 23 19:49:00 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 7D2BCDD2 for ; Fri, 23 Nov 2012 19:49:00 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 3B0BD8FC12 for ; Fri, 23 Nov 2012 19:48:59 +0000 (UTC) Received: by mail-ob0-f182.google.com with SMTP id 16so11881313obc.13 for ; Fri, 23 Nov 2012 11:48:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=pXuuhXmcJkLB05ZbFemF8jULJdQ2v/5vYzPLmilmjBU=; b=troIGBDJuJh7qBG78HyRuuDES6/wWoE6y7vgQ3DsQBumHuemkIBjzxSXdTgS5mvmaq Fg11JnJk+kYfxC3eGkF2vPgf0R7LGrxqGO77wMYYqx63Mp4CAoVAm3/iW8kTOARBx5r/ KEcVaDWG8R5h83zC0AfY9KQHOMnjBTWZxjIaYmoO3xHdBGsn+RW3tZi3l5ZlieyMrQpD ICSsEnNkgl4fX5TgqpmnYQXGUTORHieh6u1CfAx5z9nmwHCu3rkn3Q4lhcIwzvXKl0oB 0vA18rsRtYxmrBtsdxpe3qRDV6/UVvoWRtq2SeTLPPE8vBw+n8Honeaxfs8A4z48gVYb 7aAA== MIME-Version: 1.0 Received: by 10.182.172.74 with SMTP id ba10mr3681965obc.83.1353700139326; Fri, 23 Nov 2012 11:48:59 -0800 (PST) Received: by 10.76.143.33 with HTTP; Fri, 23 Nov 2012 11:48:59 -0800 (PST) In-Reply-To: References: Date: Fri, 23 Nov 2012 11:48:59 -0800 Message-ID: Subject: Re: [RFC] sema_wait_sig From: Garrett Cooper To: Oleksandr Tymoshenko Content-Type: text/plain; charset=ISO-8859-1 Cc: arch@freebsd.org 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: Fri, 23 Nov 2012 19:49:00 -0000 On Thu, Nov 22, 2012 at 10:12 PM, Oleksandr Tymoshenko wrote: > Hello, > > Is there any particular reason FreeBSD does not have sema_wait_sig > function? It seems to be easily implementable using cv_wait_sig > function. > > The reason I'm asking is that I'm getting some Linux drivers > ported to FreeBSD and the code in question relies on semaphores > and there is no obvious alternative to down_interruptible function. > I realize that not all approaches to driver development are easily > mappable from OS to OS but in this case lack of cv_wait_sig seems > like gap in API. Unless of course there is strong rationale behind it. There were a bunch of ACKs when John Polstra wanted to do work add sema_wait_sig, but it looks like the work wasn't completed (or at least not committed back to FreeBSD proper): http://unix.derkeiler.com/Mailing-Lists/FreeBSD/arch/2004-06/0074.html . HTH, -Garrett From owner-freebsd-arch@FreeBSD.ORG Sat Nov 24 15:03:55 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 3F3AE7D2 for ; Sat, 24 Nov 2012 15:03:55 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id B15278FC08 for ; Sat, 24 Nov 2012 15:03:54 +0000 (UTC) Received: by mail-lb0-f182.google.com with SMTP id go10so6848343lbb.13 for ; Sat, 24 Nov 2012 07:03:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=6nWnB7veConJ2MfUUyxpB17+g0tCUbThFb9ri6oYiSo=; b=uSvL2lpEkqvcmNDoXXQrWe3rvH+KLqf/Qh/+ycz51dNFid9/p3R6YutIllT4arinRW gHvLO+dVV56fj5y8qHPUTcPKgX5TAdMrete27ZstdS0JK0nOvul9MFtaGML1PF1RXQuZ I61B0VwK5re7HNCR9IZOH+Pb+9Tpywtb8x6aCOxKBoDjRg6Ga7jFTjf/sFKe2OTqkkO4 xCEYr4dpIXAYgx0RQZFwptduCc/B1QqY8Uf68fNx56ywDOJalGyPeR5KIxbya+QCgRHt YmiyrQcRFBLhsa09NSjjR2jQjoewWlpTPaVjPiLfwN8PDB76WvgXObnF7Uo6bV3to5Wg t4Pg== MIME-Version: 1.0 Received: by 10.152.162.1 with SMTP id xw1mr6305699lab.3.1353769433469; Sat, 24 Nov 2012 07:03:53 -0800 (PST) Sender: asmrookie@gmail.com Received: by 10.112.134.5 with HTTP; Sat, 24 Nov 2012 07:03:53 -0800 (PST) In-Reply-To: References: Date: Sat, 24 Nov 2012 15:03:53 +0000 X-Google-Sender-Auth: z9JyXj70GHhqowEVqshs5IdGa3M Message-ID: Subject: Re: [RFC] sema_wait_sig From: Attilio Rao To: Oleksandr Tymoshenko Content-Type: text/plain; charset=UTF-8 Cc: arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: attilio@FreeBSD.org 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 15:03:55 -0000 On Fri, Nov 23, 2012 at 6:12 AM, Oleksandr Tymoshenko wrote: > Hello, > > Is there any particular reason FreeBSD does not have sema_wait_sig > function? It seems to be easily implementable using cv_wait_sig > function. The sema(9) primitive is considered obsolete/dying. You should really use mtx + condvar (so just go using cv_wait_sig() directly). I had a patch to remove it all from the kernel few years ago but I never got to commit it. It would be good if we can remove this primitive off before 10.0. Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-arch@FreeBSD.ORG Sat Nov 24 15:21:14 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 A14ECABB for ; Sat, 24 Nov 2012 15:21:14 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-la0-f54.google.com (mail-la0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 1F6048FC0C for ; Sat, 24 Nov 2012 15:21:13 +0000 (UTC) Received: by mail-la0-f54.google.com with SMTP id j13so9450410lah.13 for ; Sat, 24 Nov 2012 07:21:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=To96R4aSVBHzHYgz1Gs1r1rsOXAj3/gcAdLrbUCdQ1c=; b=HPfXBzP5b1k04Aa3qX2XJUfDI3sAiUg2pPRtvvdS5lurmpp+0oyolUu+3i5YFT/lf1 guCEB51eedoa7YAS+Qtyy5NJwNOkKGTKk4cNG/WGs9qVutqFHWEXbD5Dqh5w0MD29Lo5 MWmzhxqrK6vGSNpojOGeTXjuiKKwKitUpubwYWArmNNuh/3/AKRjUwskiQqGubGewTVM GP1s4zguX7hfPmdAB66qubQXDb+DUBvdh49aqkKyKv7+FmtArvCNieUeTjBTJPmS4npX V7X2rK9NXKPYi4Ov1Tpm2zqhaosliEJlvmZyQT+vy7mdzCsTL9atxEO1Im7/F75f2DTi K+MA== MIME-Version: 1.0 Received: by 10.112.87.40 with SMTP id u8mr3036585lbz.50.1353770472717; Sat, 24 Nov 2012 07:21:12 -0800 (PST) Sender: asmrookie@gmail.com Received: by 10.112.134.5 with HTTP; Sat, 24 Nov 2012 07:21:12 -0800 (PST) In-Reply-To: References: Date: Sat, 24 Nov 2012 15:21:12 +0000 X-Google-Sender-Auth: sER0tlWPXETrFZSFO04Cvx9avXU Message-ID: Subject: Re: [RFC] sema_wait_sig From: Attilio Rao To: Oleksandr Tymoshenko Content-Type: text/plain; charset=UTF-8 Cc: arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: attilio@FreeBSD.org 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 15:21:14 -0000 On Sat, Nov 24, 2012 at 3:03 PM, Attilio Rao wrote: > On Fri, Nov 23, 2012 at 6:12 AM, Oleksandr Tymoshenko > wrote: >> Hello, >> >> Is there any particular reason FreeBSD does not have sema_wait_sig >> function? It seems to be easily implementable using cv_wait_sig >> function. > > The sema(9) primitive is considered obsolete/dying. > You should really use mtx + condvar (so just go using cv_wait_sig() directly). > > I had a patch to remove it all from the kernel few years ago but I > never got to commit it. > It would be good if we can remove this primitive off before 10.0. Before to start receiving bikeshead e-mails by "savers of the nation", let me explain this a bit. This cames directly from the necessity to shrunk the number of locking primitives we offer, in particular when such primitives have very naive/non-standard interface, meant as dangerous and not intuitive KPI. The biggest 2 beasts to chase are then sema(9) and lockmgr(9). The former should be replaced by a smart use of mtx + flags/counters + sleep(9)/condvar(9). I see some of the usage are the ones that want the first locker to sleep (counter as 0 at init time), for example. The latter should be replaced by sx(9) interface, but that's very tricky. lockmgr have a lot of strange patterns which require a fair bit of understanding and work to be controlled (LK_DRAIN, LK_SLEEPFAIL, interlock handling, lockmgr_disown(), etc.). I'm sure sx might grow up some further operations to cope with it (namely the interlock and maybe disowning) but that's really minor turbolence as removing redundant lockmgr would be a big win for us. Right now it is just a burden and more code to maintain for a very little gain. As a last item, we may also look at splitting the sleep-mtx and spin-mtx interface and replace all the occurence of the former with rwlocks, of course always held in write mode. This way the mtx(9) will only serve spinlocks and their implementation will be very self contained. Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-arch@FreeBSD.ORG Sat Nov 24 16:17:11 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 3118A766; Sat, 24 Nov 2012 16:17:11 +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 11D648FC13; Sat, 24 Nov 2012 16:17:10 +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 29AD91A3C1A; Sat, 24 Nov 2012 08:17:10 -0800 (PST) Message-ID: <50B0F306.6020906@mu.org> Date: Sat, 24 Nov 2012 08:17:10 -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: attilio@FreeBSD.org Subject: Re: [RFC] sema_wait_sig References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 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 16:17:11 -0000 On 11/24/12 7:21 AM, Attilio Rao wrote: > On Sat, Nov 24, 2012 at 3:03 PM, Attilio Rao wrote: >> On Fri, Nov 23, 2012 at 6:12 AM, Oleksandr Tymoshenko >> wrote: >>> Hello, >>> >>> Is there any particular reason FreeBSD does not have sema_wait_sig >>> function? It seems to be easily implementable using cv_wait_sig >>> function. >> The sema(9) primitive is considered obsolete/dying. >> You should really use mtx + condvar (so just go using cv_wait_sig() directly). >> >> I had a patch to remove it all from the kernel few years ago but I >> never got to commit it. >> It would be good if we can remove this primitive off before 10.0. > Before to start receiving bikeshead e-mails by "savers of the nation", > let me explain this a bit. This cames directly from the necessity to > shrunk the number of locking primitives we offer, in particular when > such primitives have very naive/non-standard interface, meant as > dangerous and not intuitive KPI. > The biggest 2 beasts to chase are then sema(9) and lockmgr(9). > > The former should be replaced by a smart use of mtx + flags/counters + > sleep(9)/condvar(9). I see some of the usage are the ones that want > the first locker to sleep (counter as 0 at init time), for example. > > The latter should be replaced by sx(9) interface, but that's very > tricky. lockmgr have a lot of strange patterns which require a fair > bit of understanding and work to be controlled (LK_DRAIN, > LK_SLEEPFAIL, interlock handling, lockmgr_disown(), etc.). I'm sure sx > might grow up some further operations to cope with it (namely the > interlock and maybe disowning) but that's really minor turbolence as > removing redundant lockmgr would be a big win for us. Right now it is > just a burden and more code to maintain for a very little gain. > > As a last item, we may also look at splitting the sleep-mtx and > spin-mtx interface and replace all the occurence of the former with > rwlocks, of course always held in write mode. This way the mtx(9) will > only serve spinlocks and their implementation will be very self > contained. > > Thanks, > Attilio > > People have been trying to "kill lockmgr" for 5+ years now. In the meanwhile discouraging people from using things that make their lives easier in porting drivers is probably wrong. 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 From owner-freebsd-arch@FreeBSD.ORG Sat Nov 24 16:21:05 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 868FE82F for ; Sat, 24 Nov 2012 16:21:05 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id 000D08FC08 for ; Sat, 24 Nov 2012 16:21:04 +0000 (UTC) Received: by mail-lb0-f182.google.com with SMTP id go10so6881245lbb.13 for ; Sat, 24 Nov 2012 08:21:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=VmTZAvovPkRo1zPO9qbTWvcNy//oSoX3tB2Vl5lD1uM=; b=goRe85sGEZELp76pQUn3YPoIm99yJWX+PUMBZKpBKlVABBWMfBCF48mBpFvUM02DxG N7VUSp8k7PgslQvD1MzdoDPCuFSe6HocPvXFyqK+pE0VJPbmbRqonsxNb+8FS5RynbYQ aKGjvNBFaVwBGe6IOuGyRFsYCH1RG2FuRZg3k5vlbyKCLiuRqHGQr5Q63WxmAKZGjBw+ yvHyZ7+UQFSQtu/cXxrHerk5H2I+xHq2Q18u7faB+jsU1LhuwHEeVZrRyvrKd5BrTtdM QErifHzLgOF1gZVo1uUr45DcVq21u3KqNVgxqx1dhse/x9UWNCIuY8itADZARv8X10Re V2rg== MIME-Version: 1.0 Received: by 10.152.104.50 with SMTP id gb18mr6490716lab.9.1353774063409; Sat, 24 Nov 2012 08:21:03 -0800 (PST) Sender: asmrookie@gmail.com Received: by 10.112.134.5 with HTTP; Sat, 24 Nov 2012 08:21:03 -0800 (PST) In-Reply-To: <50B0F306.6020906@mu.org> References: <50B0F306.6020906@mu.org> Date: Sat, 24 Nov 2012 16:21:03 +0000 X-Google-Sender-Auth: RCkEQu2KDMnYPs3Ia4afwodqXQw Message-ID: Subject: Re: [RFC] sema_wait_sig From: Attilio Rao To: Alfred Perlstein Content-Type: text/plain; charset=UTF-8 Cc: arch@freebsd.org, Oleksandr Tymoshenko X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: attilio@FreeBSD.org 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 16:21:05 -0000 On Sat, Nov 24, 2012 at 4:17 PM, Alfred Perlstein wrote: > On 11/24/12 7:21 AM, Attilio Rao wrote: >> >> On Sat, Nov 24, 2012 at 3:03 PM, Attilio Rao wrote: >>> >>> On Fri, Nov 23, 2012 at 6:12 AM, Oleksandr Tymoshenko >>> wrote: >>>> >>>> Hello, >>>> >>>> Is there any particular reason FreeBSD does not have sema_wait_sig >>>> function? It seems to be easily implementable using cv_wait_sig >>>> function. >>> >>> The sema(9) primitive is considered obsolete/dying. >>> You should really use mtx + condvar (so just go using cv_wait_sig() >>> directly). >>> >>> I had a patch to remove it all from the kernel few years ago but I >>> never got to commit it. >>> It would be good if we can remove this primitive off before 10.0. >> >> Before to start receiving bikeshead e-mails by "savers of the nation", >> let me explain this a bit. This cames directly from the necessity to >> shrunk the number of locking primitives we offer, in particular when >> such primitives have very naive/non-standard interface, meant as >> dangerous and not intuitive KPI. >> The biggest 2 beasts to chase are then sema(9) and lockmgr(9). >> >> The former should be replaced by a smart use of mtx + flags/counters + >> sleep(9)/condvar(9). I see some of the usage are the ones that want >> the first locker to sleep (counter as 0 at init time), for example. >> >> The latter should be replaced by sx(9) interface, but that's very >> tricky. lockmgr have a lot of strange patterns which require a fair >> bit of understanding and work to be controlled (LK_DRAIN, >> LK_SLEEPFAIL, interlock handling, lockmgr_disown(), etc.). I'm sure sx >> might grow up some further operations to cope with it (namely the >> interlock and maybe disowning) but that's really minor turbolence as >> removing redundant lockmgr would be a big win for us. Right now it is >> just a burden and more code to maintain for a very little gain. >> >> As a last item, we may also look at splitting the sleep-mtx and >> spin-mtx interface and replace all the occurence of the former with >> rwlocks, of course always held in write mode. This way the mtx(9) will >> only serve spinlocks and their implementation will be very self >> contained. >> >> Thanks, >> Attilio >> >> > > People have been trying to "kill lockmgr" for 5+ years now. > > In the meanwhile discouraging people from using things that make their lives > easier in porting drivers is probably wrong. > > 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. I don't have any plan to do it right now and if you want to follow this you are welcome. If you do want to do something else (like adding sema_wait_sig()) I'm opposed to it and I'm giving you my opinion on why. You can do what you want then, but at least I'm free to say publically what I think should be done to have correct code, or should I just let people which have 0 history of contributing to SMP just turn upside down all the last 15 years of work? Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-arch@FreeBSD.ORG Sat Nov 24 17:10:45 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 05433E83; Sat, 24 Nov 2012 17:10:45 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id A74B58FC14; Sat, 24 Nov 2012 17:10:44 +0000 (UTC) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.5/8.14.5/NETPLEX) with ESMTP id qAOHAZWW061389; Sat, 24 Nov 2012 12:10:35 -0500 X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.2.7 (mail.netplex.net [204.213.176.10]); Sat, 24 Nov 2012 12:10:35 -0500 (EST) Date: Sat, 24 Nov 2012 12:10:35 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Alfred Perlstein Subject: Re: [RFC] sema_wait_sig In-Reply-To: <50B0F306.6020906@mu.org> Message-ID: References: <50B0F306.6020906@mu.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: attilio@freebsd.org, arch@freebsd.org, Oleksandr Tymoshenko X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Daniel Eischen 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 17:10:45 -0000 On Sat, 24 Nov 2012, Alfred Perlstein wrote: > On 11/24/12 7:21 AM, Attilio Rao wrote: >> On Sat, Nov 24, 2012 at 3:03 PM, Attilio Rao wrote: >>> On Fri, Nov 23, 2012 at 6:12 AM, Oleksandr Tymoshenko >>> wrote: >>>> Hello, >>>> >>>> Is there any particular reason FreeBSD does not have sema_wait_sig >>>> function? It seems to be easily implementable using cv_wait_sig >>>> function. >>> The sema(9) primitive is considered obsolete/dying. >>> You should really use mtx + condvar (so just go using cv_wait_sig() >>> directly). >>> >>> I had a patch to remove it all from the kernel few years ago but I >>> never got to commit it. >>> It would be good if we can remove this primitive off before 10.0. >> Before to start receiving bikeshead e-mails by "savers of the nation", >> let me explain this a bit. This cames directly from the necessity to >> shrunk the number of locking primitives we offer, in particular when >> such primitives have very naive/non-standard interface, meant as >> dangerous and not intuitive KPI. >> The biggest 2 beasts to chase are then sema(9) and lockmgr(9). >> >> The former should be replaced by a smart use of mtx + flags/counters + >> sleep(9)/condvar(9). I see some of the usage are the ones that want >> the first locker to sleep (counter as 0 at init time), for example. >> >> The latter should be replaced by sx(9) interface, but that's very >> tricky. lockmgr have a lot of strange patterns which require a fair >> bit of understanding and work to be controlled (LK_DRAIN, >> LK_SLEEPFAIL, interlock handling, lockmgr_disown(), etc.). I'm sure sx >> might grow up some further operations to cope with it (namely the >> interlock and maybe disowning) but that's really minor turbolence as >> removing redundant lockmgr would be a big win for us. Right now it is >> just a burden and more code to maintain for a very little gain. >> >> As a last item, we may also look at splitting the sleep-mtx and >> spin-mtx interface and replace all the occurence of the former with >> rwlocks, of course always held in write mode. This way the mtx(9) will >> only serve spinlocks and their implementation will be very self >> contained. >> >> Thanks, >> Attilio >> >> > > People have been trying to "kill lockmgr" for 5+ years now. > > In the meanwhile discouraging people from using things that make their lives > easier in porting drivers is probably wrong. Have you seen how many places sema(9) is used in the kernel? Not many, and it seems trival to replace them with mtx and cv pairs. The man page even says not to use sema(9) where mutexes and condition variables will suffice. I don't think getting rid of sleep mutexes should be done. The mtx interface should be similar to the userland interface, so that it is consistent for developers. -- DE From owner-freebsd-arch@FreeBSD.ORG Sat Nov 24 18:02:56 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 6DA89C2F; Sat, 24 Nov 2012 18:02:56 +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 42A2D8FC0C; Sat, 24 Nov 2012 18:02:56 +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 A1A381A3C56; Sat, 24 Nov 2012 10:02:55 -0800 (PST) Message-ID: <50B10BCF.3080407@mu.org> Date: Sat, 24 Nov 2012 10:02:55 -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: attilio@FreeBSD.org Subject: Re: [RFC] sema_wait_sig References: <50B0F306.6020906@mu.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 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 18:02:56 -0000 On 11/24/12 8:21 AM, Attilio Rao wrote: > On Sat, Nov 24, 2012 at 4:17 PM, Alfred Perlstein wrote: >> On 11/24/12 7:21 AM, Attilio Rao wrote: >>> On Sat, Nov 24, 2012 at 3:03 PM, Attilio Rao wrote: >>>> On Fri, Nov 23, 2012 at 6:12 AM, Oleksandr Tymoshenko >>>> wrote: >>>>> Hello, >>>>> >>>>> Is there any particular reason FreeBSD does not have sema_wait_sig >>>>> function? It seems to be easily implementable using cv_wait_sig >>>>> function. >>>> The sema(9) primitive is considered obsolete/dying. >>>> You should really use mtx + condvar (so just go using cv_wait_sig() >>>> directly). >>>> >>>> I had a patch to remove it all from the kernel few years ago but I >>>> never got to commit it. >>>> It would be good if we can remove this primitive off before 10.0. >>> Before to start receiving bikeshead e-mails by "savers of the nation", >>> let me explain this a bit. This cames directly from the necessity to >>> shrunk the number of locking primitives we offer, in particular when >>> such primitives have very naive/non-standard interface, meant as >>> dangerous and not intuitive KPI. >>> The biggest 2 beasts to chase are then sema(9) and lockmgr(9). >>> >>> The former should be replaced by a smart use of mtx + flags/counters + >>> sleep(9)/condvar(9). I see some of the usage are the ones that want >>> the first locker to sleep (counter as 0 at init time), for example. >>> >>> The latter should be replaced by sx(9) interface, but that's very >>> tricky. lockmgr have a lot of strange patterns which require a fair >>> bit of understanding and work to be controlled (LK_DRAIN, >>> LK_SLEEPFAIL, interlock handling, lockmgr_disown(), etc.). I'm sure sx >>> might grow up some further operations to cope with it (namely the >>> interlock and maybe disowning) but that's really minor turbolence as >>> removing redundant lockmgr would be a big win for us. Right now it is >>> just a burden and more code to maintain for a very little gain. >>> >>> As a last item, we may also look at splitting the sleep-mtx and >>> spin-mtx interface and replace all the occurence of the former with >>> rwlocks, of course always held in write mode. This way the mtx(9) will >>> only serve spinlocks and their implementation will be very self >>> contained. >>> >>> Thanks, >>> Attilio >>> >>> >> People have been trying to "kill lockmgr" for 5+ years now. >> >> In the meanwhile discouraging people from using things that make their lives >> easier in porting drivers is probably wrong. >> >> 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. > I don't have any plan to do it right now and if you want to follow > this you are welcome. > If you do want to do something else (like adding sema_wait_sig()) I'm > opposed to it and I'm giving you my opinion on why. > > You can do what you want then, but at least I'm free to say publically > what I think should be done to have correct code, or should I just let > people which have 0 history of contributing to SMP just turn upside > down all the last 15 years of work? > > Attilio > > Attilio, Please grep smp in http://people.freebsd.org/~alfred/alfred.logs.txt. It's not a lot, but it was when we first started going SMP and I worked very hard on this. Select locking, Filedesc locking, struct file... :) I guess this is a nice welcome back to the project. :) -Alfred From owner-freebsd-arch@FreeBSD.ORG Sat Nov 24 18:06:41 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 7B6C2CE9; Sat, 24 Nov 2012 18:06:41 +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 4FB018FC13; Sat, 24 Nov 2012 18:06:41 +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 CF7D61A3C1A; Sat, 24 Nov 2012 10:06:40 -0800 (PST) Message-ID: <50B10CB0.6040406@mu.org> Date: Sat, 24 Nov 2012 10:06:40 -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: Daniel Eischen Subject: Re: [RFC] sema_wait_sig References: <50B0F306.6020906@mu.org> In-Reply-To: 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 18:06:41 -0000 On 11/24/12 9:10 AM, Daniel Eischen wrote: > On Sat, 24 Nov 2012, Alfred Perlstein wrote: > >> On 11/24/12 7:21 AM, Attilio Rao wrote: >>> On Sat, Nov 24, 2012 at 3:03 PM, Attilio Rao >>> wrote: >>>> On Fri, Nov 23, 2012 at 6:12 AM, Oleksandr Tymoshenko >>>> wrote: >>>>> Hello, >>>>> >>>>> Is there any particular reason FreeBSD does not have sema_wait_sig >>>>> function? It seems to be easily implementable using cv_wait_sig >>>>> function. >>>> The sema(9) primitive is considered obsolete/dying. >>>> You should really use mtx + condvar (so just go using cv_wait_sig() >>>> directly). >>>> >>>> I had a patch to remove it all from the kernel few years ago but I >>>> never got to commit it. >>>> It would be good if we can remove this primitive off before 10.0. >>> Before to start receiving bikeshead e-mails by "savers of the nation", >>> let me explain this a bit. This cames directly from the necessity to >>> shrunk the number of locking primitives we offer, in particular when >>> such primitives have very naive/non-standard interface, meant as >>> dangerous and not intuitive KPI. >>> The biggest 2 beasts to chase are then sema(9) and lockmgr(9). >>> >>> The former should be replaced by a smart use of mtx + flags/counters + >>> sleep(9)/condvar(9). I see some of the usage are the ones that want >>> the first locker to sleep (counter as 0 at init time), for example. >>> >>> The latter should be replaced by sx(9) interface, but that's very >>> tricky. lockmgr have a lot of strange patterns which require a fair >>> bit of understanding and work to be controlled (LK_DRAIN, >>> LK_SLEEPFAIL, interlock handling, lockmgr_disown(), etc.). I'm sure sx >>> might grow up some further operations to cope with it (namely the >>> interlock and maybe disowning) but that's really minor turbolence as >>> removing redundant lockmgr would be a big win for us. Right now it is >>> just a burden and more code to maintain for a very little gain. >>> >>> As a last item, we may also look at splitting the sleep-mtx and >>> spin-mtx interface and replace all the occurence of the former with >>> rwlocks, of course always held in write mode. This way the mtx(9) will >>> only serve spinlocks and their implementation will be very self >>> contained. >>> >>> Thanks, >>> Attilio >>> >>> >> >> People have been trying to "kill lockmgr" for 5+ years now. >> >> In the meanwhile discouraging people from using things that make >> their lives easier in porting drivers is probably wrong. > > Have you seen how many places sema(9) is used in the kernel? Not > many, and it seems trival to replace them with mtx and cv pairs. > The man page even says not to use sema(9) where mutexes and condition > variables will suffice. > > I don't think getting rid of sleep mutexes should be done. The > mtx interface should be similar to the userland interface, so > that it is consistent for developers. > I know, it's trivial to replace lots of things with their constituent parts, until it's "all the things" and then you're spending all your time re-writing semaphores and mutexes and doing busy work instead of getting code done. But hey, if it bothers you so much that someone can easily port over Linux drivers, or that a Linux kernel dev can come to FreeBSD and easily get up to speed... then pull the rug out from under them. I guess. :) It doesn't make sense to me, but I don't really get the make-FreeBSD-hard-to-use-and-code-for group-think. Maybe eventually. :) -Alfred From owner-freebsd-arch@FreeBSD.ORG Sat Nov 24 19:30:11 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 01DCA6A8; Sat, 24 Nov 2012 19:30:11 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (pancho.soaustin.net [76.74.250.40]) by mx1.freebsd.org (Postfix) with ESMTP id D1ADD8FC13; Sat, 24 Nov 2012 19:30:10 +0000 (UTC) Received: by mail.soaustin.net (Postfix, from userid 502) id 665875602F; Sat, 24 Nov 2012 13:30:10 -0600 (CST) Date: Sat, 24 Nov 2012 13:30:10 -0600 From: Mark Linimon To: Alfred Perlstein Subject: Re: [RFC] sema_wait_sig Message-ID: <20121124193010.GB1627@lonesome.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50B0F306.6020906@mu.org> User-Agent: Mutt/1.5.20 (2009-06-14) 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:30:11 -0000 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. mcl 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 From owner-freebsd-arch@FreeBSD.ORG Sat Nov 24 21:52:26 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 61383E4B for ; Sat, 24 Nov 2012 21:52:26 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id D46C88FC12 for ; Sat, 24 Nov 2012 21:52:25 +0000 (UTC) Received: by mail-lb0-f182.google.com with SMTP id go10so6992690lbb.13 for ; Sat, 24 Nov 2012 13:52:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=AWBbx+4mcAsEEpcSgo5GDiX1BvYH4yf4I1ic+zne+Hg=; b=sBtuRwqrEbTK3OyTE9Z/oE2SHpDlnfSluEMAUJmG9Yw756fgYK0F50O1UcksfW/Cj+ w2uunYnqkE+a5rG+Z905Yuw6ZyFr5guQVbYMHbOI3Bt+ZP8MtWGgr/kPnZN20JvTtfKh /vPsBuHeLInoTsvirjY5rQTyDESQTiR9duV1J+54Hu1FYZVxmi27qJngqBEGp6WdeluG qiFbHlioyZhNv2qmqk+ugZNtYmkp44QsMNaSvf4iz5N2zalONuD8WUYEl39QDO+xtK+z orQuPMqC2VMG+J6LtFfFy1FoUW/ezdVk7kOKf52bWhpn6E9azZHSrTwzGnOLO0zrzQkY G97Q== MIME-Version: 1.0 Received: by 10.152.129.197 with SMTP id ny5mr6865074lab.43.1353793944355; Sat, 24 Nov 2012 13:52:24 -0800 (PST) Sender: asmrookie@gmail.com Received: by 10.112.134.5 with HTTP; Sat, 24 Nov 2012 13:52:24 -0800 (PST) In-Reply-To: <50B12520.7040508@mu.org> References: <20121124193010.GB1627@lonesome.com> <50B12520.7040508@mu.org> Date: Sat, 24 Nov 2012 21:52:24 +0000 X-Google-Sender-Auth: 2oeYQEqSaE9stUUYOMkMtRCQI9s Message-ID: Subject: Re: [RFC] sema_wait_sig From: Attilio Rao To: Alfred Perlstein Content-Type: text/plain; charset=UTF-8 Cc: Mark Linimon , Oleksandr Tymoshenko , arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: attilio@FreeBSD.org 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 21:52:26 -0000 On Sat, Nov 24, 2012 at 7:50 PM, Alfred Perlstein wrote: > 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. I will skip comments on your attitude, mindset, etc. (trying to let me appear as the bad cop or play at "who is better") but just reply to technical points. > 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. I would like to see it replaced by sx locks. > 2. sema will be replaced/rototilled by something. I already said that it will be replaced by mtx + condvar. > 3. sleep mutexes and spin mutex will have API rototilled by something into > something else. I already said that I would like to see it replaced by rwlocks. > 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". Oh, this is just something you are saying. I didn't say it is "unclean". I say it is completely wrong and completely redundant. Why should we favourite code duplication? What is the reason? Why should we keep sema(9) interface when you can implement exactly the same logic with a mutex and a condvar? There is a technical reason? Can you make a real point out of it? Why we should keep sema(9)? > Lockmgr has been a ... "pain" forever, it should go or at least never ever > be used by anything but VFS. My point on lockmgr() is that their basic mechanism is completely redundant with sx. There are features they provide that are very unique and that are very important for the buffer cache (disowning) or VFS (interlock) but I think we can merge them with sx and be done with it. > But back to the point, this isn't a roadmap, this is churn for the sake of > churn. These are milestones that we can break up in smaller pieces to make a plan out of them. > For aesthetics. No, this is for code maintenance. > It's not right and you know it. Don't put words into my mouth. It is right and I know it. Ah and let me give you a piece of warning: bullying your opinions over me is not going bringing you anywhere. I'm not a stupid doll you can direct at your liking and I have a skin ticker enough to support my ideas. And finally I always try to give technical resons on things I propose, despite your attitude to rework my words or entirely skip them. Stop it. Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-arch@FreeBSD.ORG Sat Nov 24 22:10:14 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 539DB15D; Sat, 24 Nov 2012 22:10:14 +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 334588FC14; Sat, 24 Nov 2012 22:10:14 +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 7A0581A3C56; Sat, 24 Nov 2012 14:10:13 -0800 (PST) Message-ID: <50B145C5.8070503@mu.org> Date: Sat, 24 Nov 2012 14:10:13 -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: attilio@FreeBSD.org Subject: Re: [RFC] sema_wait_sig References: <20121124193010.GB1627@lonesome.com> <50B12520.7040508@mu.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Mark Linimon , Oleksandr Tymoshenko , arch@freebsd.org 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 22:10:14 -0000 I don't understand why you are the one who is so upset. Your first email to me implied that I had 0 smp experience. Let me explain why this rototilling is unneeded. Go download a copy of linux and observe the following: spin_lock(&mb_cache_spinlock); spin_unlock(&mb_cache_spinlock); spin_lock_irqsave, spin_unlock_irqrestore up() down(dqio_mutex) Those apis have been available for a decade at least. I'll cut to the point on this. If you want to change HOW the underlying freebsd SMP api works to improve performance, then please do! But if you want to change the actual KPI, then please realize that Linux SMP does darn well with a KPI for SMP that's pretty much unchanged for nearly 10 years. I would venture to say in this respect we've become what we used to mock Linux for, an OS that gratuitously changes interfaces for the sake of what is cool, versus what our vendors need. My goal is not to offend you, it's to explain why maintaining a stable API (which Linux somehow is doing better than us) is a worthwhile task. Maybe something is getting lost in my point here, but it's seriously not to offend, just show how it's done and how it can help us. thank you, -Alfred On 11/24/12 1:52 PM, Attilio Rao wrote: > On Sat, Nov 24, 2012 at 7:50 PM, Alfred Perlstein wrote: >> 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. > I will skip comments on your attitude, mindset, etc. (trying to let me > appear as the bad cop or play at "who is better") but just reply to > technical points. > >> 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. > I would like to see it replaced by sx locks. > >> 2. sema will be replaced/rototilled by something. > I already said that it will be replaced by mtx + condvar. > >> 3. sleep mutexes and spin mutex will have API rototilled by something into >> something else. > I already said that I would like to see it replaced by rwlocks. > >> 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". > Oh, this is just something you are saying. I didn't say it is > "unclean". I say it is completely wrong and completely redundant. Why > should we favourite code duplication? What is the reason? > > Why should we keep sema(9) interface when you can implement exactly > the same logic with a mutex and a condvar? There is a technical > reason? Can you make a real point out of it? Why we should keep > sema(9)? > >> Lockmgr has been a ... "pain" forever, it should go or at least never ever >> be used by anything but VFS. > My point on lockmgr() is that their basic mechanism is completely > redundant with sx. There are features they provide that are very > unique and that are very important for the buffer cache (disowning) or > VFS (interlock) but I think we can merge them with sx and be done with > it. > >> But back to the point, this isn't a roadmap, this is churn for the sake of >> churn. > These are milestones that we can break up in smaller pieces to make a > plan out of them. > >> For aesthetics. > No, this is for code maintenance. > >> It's not right and you know it. > Don't put words into my mouth. It is right and I know it. > > Ah and let me give you a piece of warning: bullying your opinions over > me is not going bringing you anywhere. I'm not a stupid doll you can > direct at your liking and I have a skin ticker enough to support my > ideas. > And finally I always try to give technical resons on things I propose, > despite your attitude to rework my words or entirely skip them. > Stop it. > > Attilio > >