From owner-svn-src-stable@freebsd.org Fri Mar 9 16:22:34 2018 Return-Path: Delivered-To: svn-src-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F27E4F3651C for ; Fri, 9 Mar 2018 16:22:33 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7AA797F240 for ; Fri, 9 Mar 2018 16:22:33 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x234.google.com with SMTP id c11so3351213ith.4 for ; Fri, 09 Mar 2018 08:22:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=hUswTB+N4b6f2rOfvb7jsLG+DNUb4axtd47iKyVE8TE=; b=Pb2Lo1mVIudCaiq/v/80j572TEMzGSaOEsQXIzxq87c47+XSb0L40YON9XAnIQzZ5F Hh+lJuZo8jAwpaO19QitmoLn2HZQKkwyZqQE0Eib0JtR2cIBI5yPq4qSSU8XQzFozl6F xAH+OZ+ZN4Y1qGYZRLIg9ornTYXWU6wnElgQhqlaK5TtgI+6kmPZk6hIO3YhKQmJRpSq 6Ei9uTjtIRZidnDzGbhZb+3Rt+cWmkgB2lxAiTALf2loH2qmOjU0B15YVzG58ZJzQubb +fBlpC87YhCc+2qkzkt3YO0FAKBGNcOEAWNqkjr7xO1r2G/qLKmXBkV2cGTWdCBg8Qtn 8cxQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=hUswTB+N4b6f2rOfvb7jsLG+DNUb4axtd47iKyVE8TE=; b=Mj16b9JqeO3z2kALZBtPtcFF+PTSKbzpSCXsk2wA8zZPrMlSjJJugd80MEJt//8Y3o 6TR9+itaxVNCUjzdfo/d9uXN0f7/qwXTplY7/YQyRs/4KBrdagSkvQI5GjTvyOj4Ugys VrzoVVtwFWivXwPUbjUkYRYzrgOTCdfeVUv5NZXSC4ocq1JzIcVmaLaVuzdbdeKpwV1W INZBCurVrouvyqiJ7skIdCOAqJYpdCjVu6oCWXvhIOxhIfLDY3+uuUSUgQztTshZ/7ak UvhUSssox9HYevUk8Uxf5oK9HUQuraXUCuqNXHip0+mYTPOCiJ0KcVKKMg8o65PGA/N5 iVwQ== X-Gm-Message-State: AElRT7EYQi4N+Fxe5hkQCpRMgGlVKHb1dcsEZh2VaEvKfK3xymTXve8l TI9jw9xkIRZmP1SXFC2oLsIOApJAn1p6D4RCr38JZA== X-Google-Smtp-Source: AG47ELvVskXGSfcRIE4nYP7tO73pBZe1C7tYJYCLaEyTQzLVnJ3c0Yz+hjtpCEG5Pd6koHvQbH8ptaPwLiEXCjAiKaI= X-Received: by 10.36.4.65 with SMTP id 62mr4118914itb.57.1520612552664; Fri, 09 Mar 2018 08:22:32 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.203.196 with HTTP; Fri, 9 Mar 2018 08:22:31 -0800 (PST) X-Originating-IP: [2603:300b:6:5100:18a2:a4f7:170:8dd9] In-Reply-To: <201803091609.w29G9kI1065167@pdx.rh.CN85.dnsmgr.net> References: <201803091609.w29G9kI1065167@pdx.rh.CN85.dnsmgr.net> From: Warner Losh Date: Fri, 9 Mar 2018 09:22:31 -0700 X-Google-Sender-Auth: jFN5_qz-eSFb3uA_qr8sJQjDZFU Message-ID: Subject: Re: svn commit: r330451 - in stable/11/sys: dev/iwm dev/otus dev/usb/wlan net80211 To: "Rodney W. Grimes" Cc: Kyle Evans , svn-src-stable@freebsd.org, svn-src-all@freebsd.org, src-committers , svn-src-stable-11@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: svn-src-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: SVN commit messages for all the -stable branches of the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2018 16:22:34 -0000 On Fri, Mar 9, 2018 at 9:09 AM, Rodney W. Grimes < freebsd@pdx.rh.cn85.dnsmgr.net> wrote: > > On Fri, Mar 9, 2018 at 9:28 AM, Rodney W. Grimes > > wrote: > > >> On Wed, Mar 07, 2018 at 02:53:49PM -0800, Eitan Adler wrote: > > >> > On 7 March 2018 at 09:37, John Baldwin wrote: > > >> > > ... > > >> > > I suspect many of these changes for iwm, etc. are all intertwined > > >> > > so I'm not sure if you can leave out individual ones. > > >> > > > >> > Possibly. I do have iwm working on my laptop though. I also know of > > >> > one open PR assigned to me w.r.t. a model I don't own. I'll be > > >> > addressing it some time this week. > > >> > > >> I often have mixed feelings when I see lots of similar changes (i.e. > > >> that make up for better hardware support, esp. on a laptop) MFCed. > > >> I'd rather see laptop users run -CURRENT and leave -STABLE branches > > >> for very conservative (server?) users who can't/don't want to afford > > >> the risks of running -CURRENT or require ABI stability in a really > > >> long run, rather than binge-merging things. :-) > > >> > > >> By default it should be -CURRENT all over; it's a very good thing > > >> that we as a Project ourselves are doing this as part of our own > > >> dogfood eating strategy. > > > > > > As a data point just last night a person came into #freebsd irc > > > channel with a none working wireless nic on a desktop, he was > > > attemtping to use a Realteak RTL8192EU on 11.1-RELEASE. > > > > > > Someone had already told him to try urtwn driver, which in > > > -current is the right driver and supports this device. > > > > > > It did not work for him. This is about when I came in to the > > > discussion, and helped to confirm that -current did infact > > > have support for this device, and that this supported had > > > existed in -current for 16 months, and that this support > > > would not be a simple grab a couple driver files and build > > > it on 11.1. > > > > > > The commit to add this support involves 46 files, which 18 > > > of are new files. > > > > > > My feelings are if this driver has been in -current for > > > 16 months why is it NOT in -stable yet? I know part of > > > the answer "its not a simple merge". But as a project > > > this is egg on our face. We can merge a new very complicated > > > change to a our boot code, within a few months (thank you > > > kevans for that work), but we can not merge back a > > > device driver in 16? > > > > > > > I had the same questions- this exact same person had hopped over to > > #freebsd-wifi and I had walked through this same process, identifying > > it as "not MFC-able" at this point because so many commits having been > > left un-merged prior to it. I've already recently gone through the fun > > of catching up on one and a half years worth of unmerged work in > > stand, I'm not really prepared to do it again quite yet. > > But but but.. you did it so well the first time!!! :-) > I can fully appreciate that you do not desire to do another > massive merge. > > > It felt pretty bad having to tell him that his only option here was to > > either hop on -CURRENT + rtwn(4) or grab a stable/11 supported NIC- > > especially since stable/11 is still supposed to be supported for > > another three (3!) years, and I had to leave before I could help him > > walk through getting it setup on -CURRENT properly. > > When I left the #freebsd channel he was downloading, and others > there are capable of helping him get up and running. > > One thing that did come up while discussing some of the issues > with merging head to stable was it might be usefull if we add > yet another marker line: > Changes ABI/KABI: yes > to the commit messages, at least if marked you can be pretty > sure that merging is going to involve additional work, lack > of this mark would not guarantee you didnt have an ABI issue > as they are easy to overlook and you would still need to > look for those types of problems. > Given our past experience, it is often the case that people make changes and aren't aware it's an ABI change, or forget that it is an ABI change once testing is done. Or not realize a change in place X affects Y that affects Z that makes it an ABI change. We've had several changes to CAM that we had to redo because people didn't realize they were breaking something. And at least one of them I approved knowing what changed, but not groking the implications of the change. > I have been told by someone there are some tools that can > mechanically look for ABI changes. > This is the only way forward that may work, but it's much harder in the kernel where the interfaces aren't well enumerated. But we have to look at why so much is desirable to MFC. It's been a long time since a major release and a lot has gone into 12 on the assumption the release would be maybe 30 months from 11.0. The current schedule doesn't have it going out for quite some time. Another way forward is to pull in the 12.0R release. If there were an impending major release, it wouldn't be so bad. However, the agreed to release schedule a few years ago is slipping, which is putting pressure to MFC things, which is why we're talking about this. 11.0 was released in October 2016. That means we should be entering a code slush this summer for 12.0 towards the end of the year, but so far the best guess is a vague hand wave of sometime in early 2019, maybe. That's what's creating the pressure to MFC: we have at least one more year of 11 being the latest release. Warner