From owner-svn-src-all@FreeBSD.ORG Tue Nov 6 23:47:07 2012 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A8D5C186; Tue, 6 Nov 2012 23:47:07 +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 41A9A8FC12; Tue, 6 Nov 2012 23:47:05 +0000 (UTC) Received: by mail-lb0-f182.google.com with SMTP id b5so1099185lbd.13 for ; Tue, 06 Nov 2012 15:47:04 -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=bYalc62H9VlAVEWlfnRALIJOZL9JyRtVBue3UsiBMGM=; b=OpbFB/ZL96BVChvplc13k3/FZ8wXPm0Rn/y7kfvKXDuXQa0fOh8YGlb/rRA1XTIoNh qJujnBVGnB8aWV/neEirxlc2K/JP2IfH2HPKuSdXMRwRuEfi60xAd5TV6sQ0iGNLHHne qPtFIF3uzaQoMK15gr789+MkYzZla0c5MXMnQm3Re/8x5lroAQSsIGJQ5RsUdUOMkupk v3BoFQS8Ki0D6X8/hdBoDyNjRhd9L8P72SRQ+VOX4PU/IOUdSkTGSGHiADDoxOfmDL/B o2RUB5JX3aAUIMnSa+y4owTD/93czrEcPhdChpD6WazQJcMB9K7NAMieXmPK4pQpnV8Z e8Ug== MIME-Version: 1.0 Received: by 10.112.82.103 with SMTP id h7mr1195532lby.50.1352245624739; Tue, 06 Nov 2012 15:47:04 -0800 (PST) Sender: asmrookie@gmail.com Received: by 10.112.30.37 with HTTP; Tue, 6 Nov 2012 15:47:04 -0800 (PST) In-Reply-To: <50999F66.1020402@FreeBSD.org> References: <201210221750.q9MHot26061585@svn.freebsd.org> <50999F66.1020402@FreeBSD.org> Date: Tue, 6 Nov 2012 23:47:04 +0000 X-Google-Sender-Auth: IaQaqObNR3PIQ_pMovd3xVedZOA Message-ID: Subject: Re: svn commit: r241896 - in head: . cddl/contrib/opensolaris/lib/libzpool/common/sys share/man/man9 sys/cam/ctl sys/cddl/compat/opensolaris/kern sys/cddl/compat/opensolaris/sys sys/cddl/contrib/openso... From: Attilio Rao To: Alexander Motin Content-Type: text/plain; charset=UTF-8 Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Konstantin Belousov , Ben Kaduk X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: attilio@FreeBSD.org List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 23:47:07 -0000 On Tue, Nov 6, 2012 at 11:38 PM, Alexander Motin wrote: > On 07.11.2012 01:20, Attilio Rao wrote: >> >> On Tue, Nov 6, 2012 at 11:17 PM, Ben Kaduk wrote: >>> >>> I do not wish to belabor the point; we all have better things to do >>> with our time. Hopefully this is my last message on the topic. >>> >>> On Tue, Nov 6, 2012 at 6:10 PM, Attilio Rao wrote: >>> >>>> The point is that KPI/KBI of -CURRENT can change as long as >>>> __FreeBSD_version is bumped (and if you really want to know my >>>> opinion, I already see this as a forceful thing because it would not >>>> be necessary in my mind, but I second the will of the majority of >>>> developers). So, if the KPI/KBI changes all the thirdy part code, >>>> ports and everything else must adapt. >>> >>> >>> Yes, everything must adapt to changes in -current. I am arguing that, >>> if it is easy to do so, we should make the user experience for >>> *ordinary users* running -current as nice as possible. If we do not >>> have ordinary users running current, then our code does not get >>> real-world testing until RC builds, or even the .0 release. I think >>> it is well-accepted that we want to have the code in -current get >>> real-world testing; making the user experience nicer helps this to >>> happen. To me, it seems that the user experience is nicer if the KPI >>> change is delayed from the KBI change. We have mechanisms in place >>> that can enforce __FreeBSD_Version of kernel modules must match the >>> version of the running kernel, so I do not see how this procedure >>> would lead to silent binary incompatibility. >> >> >> The courtesy you are mentioning here is the __FreeBSD_Version. Having >> stricter rule would just meaning doing under-performing and unclean >> job. >> >>> >>>> MPSAFE flag is not any longer supported and code needs to be ported >>>> appropriately to -CURRENT interface. >>> >>> >>> That is the present state of affairs, yes. I am asking only, "think >>> of the users; can we make things easier for them?". >>> Maybe not in this case, but as something to keep in mind for the future. >> >> >> I can understand your concern, but people using -CURRENT must be well >> aware of the fact that this is a development branch and they cannot >> expect too many safety belt mechanisms to be in place. >> >> I think that the current model (break KBI/KPI at will, give >> ports/thirdy part a way to recognize it via __FreeBSD_Version and move >> on) is optimal because it doesn't limit the developer neither leaves >> the user completely without a landmark on how to fix the problem. >> >> It is all balancing in finding compromises :) > > > I would like to support Ben's position. We may not expect that all the world > is tracking our development in real time and adapt to our changes at the > same exact moment. As I understand, before this one change MPSAFE flag was > mandatory to have. After that one change MPSAFE is missing and so must to be > removed. Yes, in perspective that part of code in external sources will be > wrapped with respective ifdef's, but could we give world some time window to > adapt, leaving constant doing nothing in tree? What is the price of having > single define, comparing to headache even for one user who was brave enough > to run HEAD? This is bad for specifically a reason: it won't give people reason to clean up their code and align to the new KPI. They will just stick with the broken code and the compat stub and will live with it until we don't remove also the compat stub. And then they could ask for another "compat windows" again and then over and over. I think this is all nosense, really. Attilio -- Peace can only be achieved by understanding - A. Einstein