Date: Tue, 24 Jun 2014 13:56:51 +0900 From: "Lundberg, Johannes" <johannes@brilliantservice.co.jp> To: Hans Petter Selasky <hps@selasky.org> Cc: FreeBSD Current <freebsd-current@freebsd.org> Subject: Re: ucom_free Fatal trap on shutdown / module unload Message-ID: <CAASDrVnfxR40OsJLRLQUfyzhBHuHynYAqmaq=9EBUxZHMUCYnw@mail.gmail.com> In-Reply-To: <53A90116.7040306@selasky.org> References: <CAASDrVkFfhyU8Jb4EB%2B4V32skfFijX9TKLSysjGK=0ye=G9GgA@mail.gmail.com> <53A3E81B.5050805@selasky.org> <CAASDrVnpVgmP4zg0jbqAc197DnX5_bgWRE3pA08foRMF6N9WVQ@mail.gmail.com> <53A79732.6060705@selasky.org> <CAASDrVkBjqoKFTF48Vyv3dRRUxKfVpCZ5uMjb7P%2BMy_tnGOF7w@mail.gmail.com> <53A90116.7040306@selasky.org>
next in thread | previous in thread | raw e-mail | index | archive | help
SGkNCg0KV2VsbCBJJ20gcnVubmluZyB0aGUgc25hcGhvdCBtZW1zdGljayBpbWFnZSBmcm9tIEp1 bmUgb2YgMTEtQ1VSUkVOVCBhbWQ2NCwNCndpdGggbmV3Y29ucy4NCg0KVGhlIGRldmljZSBpcyBl bWJlZGRlZCBpbiB0aGUgbGFwdG9wIGFuZCBJIGNhbiBub3QgcmVtb3ZlIGl0IGVhc2lseSBzbyBJ DQpkb24ndCBrbm93IHdoYXQgd291bGQgaGFwcGVuIGlmIEkgZG8uDQoNCkknbSBzZW5kaW5nIHlv dSB0aGUgc2NyZWVuc2hvdHMgc2VwYXJhdGVseSBpbiBkaXJlY3QgbWFpbCBzbyB3ZSBkb24ndCBo YXZlDQp0byB3YWl0IGZvciBsYXJnZSBhdHRhY2htZW50IGFwcHJvdmFsIG9uIHRoZSBsaXN0Lg0K DQoNCg0KDQotLQ0KSm9oYW5uZXMgTHVuZGJlcmcNCkJSSUxMSUFOVFNFUlZJQ0UgQ08uLCBMVEQu DQoNCg0KT24gVHVlLCBKdW4gMjQsIDIwMTQgYXQgMTozOSBQTSwgSGFucyBQZXR0ZXIgU2VsYXNr eSA8aHBzQHNlbGFza3kub3JnPg0Kd3JvdGU6DQoNCj4gT24gMDYvMjMvMTQgMDc6MzQsIEx1bmRi ZXJnLCBKb2hhbm5lcyB3cm90ZToNCj4NCj4+IEkgYWRkZWQgc29tZSBsb2dnaW5nIHRvIHNlZSB3 aGF0IGlzIGdvaW5nIG9uIGFuZCB0aGlzIGlzIHdoYXQgSSBnb3QgKG5vbmUNCj4+IG9mIHRoZSBw cm9wb3NlZCBzb2x1dGlvbiBzb2x2ZWQgdGhlIHByb2JsZW0pDQo+Pg0KPj4gdWhzb19kZXRhY2gg Z2V0cyBjYWxsZWQgNyB0aW1lcyAoZm9yIG9pZCAwLTYpLiBJdCBjcmFzaGVzIHRoZSAybmQgdGlt ZSBvbg0KPj4gdGhlIGNhbGwgdXNiZF90cmFuc2Zlcl91bnNldHVwKHNjLT5zY194ZmVyLCAzKTsN Cj4+DQo+Pg0KPiBIaSwNCj4NCj4gWW91IGFyZSBydW5uaW5nIC1zdGFibGUgcHJlc3VtYWJseT8N Cj4NCj4gQ2FuIHlvdSBzZXQgaHcudXNiLmRlYnVnPTE2IGFuZCBjb2xsZWN0cyB0aGUgMTAgbGFz dCBwcmludHMgYmVmb3JlIHRoZQ0KPiBwYW5pYywgYW5kIGJhY2t0cmFjZSB3b3VsZCBiZSBuaWNl IHRvby4gVGhpcyBkb2VzIG5vdCBoYXBwZW4gd2hlbiB5b3UNCj4gdW5wbHVnIHRoZSBkZXZpY2Us IGNvcnJlY3Q/DQo+DQo+IC0tSFBTDQo+DQo+DQoKLS0gCj0tPS09LT0tPS09LT0tPS09LT0tPS09 LT0tPS09LT0tPS09LT0tPS09LT0tPS09LT0tPS09LQrnp5jlr4bkv53mjIHjgavjgaTjgYTjgabv vJrjgZPjga7pm7vlrZDjg6Hjg7zjg6vjga/jgIHlkI3lrpvkurrjgavpgIHkv6HjgZfjgZ/jgoLj ga7jgafjgYLjgorjgIHnp5jljL/nibnmqKnjga7lr77osaHjgajjgarjgovmg4XloLHjgpLlkKvj gpPjgafjgYTjgb7jgZnjgIIK44KC44GX44CB5ZCN5a6b5Lq65Lul5aSW44Gu5pa544GM5Y+X5L+h 44GV44KM44Gf5aC05ZCI44CB44GT44Gu44Oh44O844Or44Gu56C05qOE44CB44GK44KI44Gz44GT 44Gu44Oh44O844Or44Gr6Zai44GZ44KL5LiA5YiH44Gu6ZaL56S644CBCuikh+WGmeOAgemFjeW4 g+OAgeOBneOBruS7luOBruWIqeeUqOOAgeOBvuOBn+OBr+iomOi8ieWGheWuueOBq+WfuuOBpeOB j+OBhOOBi+OBquOCi+ihjOWLleOCguOBleOCjOOBquOBhOOCiOOBhuOBiumhmOOBhOeUs+OBl+S4 iuOBkuOBvuOBmeOAggotLS0KQ09ORklERU5USUFMSVRZIE5PVEU6IFRoZSBpbmZvcm1hdGlvbiBp biB0aGlzIGVtYWlsIGlzIGNvbmZpZGVudGlhbAphbmQgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUg YWRkcmVzc2VlLgpEaXNjbG9zdXJlLCBjb3B5aW5nLCBkaXN0cmlidXRpb24gb3IgYW55IG90aGVy IGFjdGlvbiBvZiB1c2Ugb2YgdGhpcwplbWFpbCBieSBwZXJzb24gb3RoZXIgdGhhbiBpbnRlbmRl ZCByZWNpcGllbnQsIGlzIHByb2hpYml0ZWQuCklmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCBy ZWNpcGllbnQgYW5kIGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbgplcnJvciwgcGxlYXNlIGRl c3Ryb3kgdGhlIG9yaWdpbmFsIG1lc3NhZ2UuCg== From owner-freebsd-current@FreeBSD.ORG Tue Jun 24 05:42:28 2014 Return-Path: <owner-freebsd-current@FreeBSD.ORG> Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1538E174 for <freebsd-current@freebsd.org>; Tue, 24 Jun 2014 05:42:28 +0000 (UTC) Received: from mail-ie0-f179.google.com (mail-ie0-f179.google.com [209.85.223.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C67182F8D for <freebsd-current@freebsd.org>; Tue, 24 Jun 2014 05:42:27 +0000 (UTC) Received: by mail-ie0-f179.google.com with SMTP id tr6so6939862ieb.38 for <freebsd-current@freebsd.org>; Mon, 23 Jun 2014 22:42:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=UkOMUoRvNh5mUtq92B2fuWMDausX0jU4PzQqAT1sTzI=; b=hT/pWeWxwAW84pXIhvEHd9J/jrs2d3paX5Y0CIO5fnwBl87sHpC5QNbi58FVNlEEFN 7MaMked1rqfIELPmjj2822YdgtGlpRvUVHBIsLBrayvhjGi+8XbwSbkam7C9d9Fo+meR YOH+Ff4+YhBR7C38OegH/pejoV7+8AXtlwkMJ/lGHmb3XWDtgqtDuAdTxo5gf4LhxpC3 VQLyfLgs/0tKuJMscV3jI77HvUrTvKoiNj1Vv8S9IBMJRfHyKy9VIwxCgF+91pLp2bW4 QQCWUR7AIt0nYu6aiLH34zosj2mcTNfgnsdESdLRW9x+KRL8HuPaA9u7F8FjEEPVDj06 E7VA== X-Gm-Message-State: ALoCoQlR/6hfph2f72bmAtTS8TodVk63rSthy9sGAKtSCuffRjige0VsdDHsq7xYmVRpEixuZVEx X-Received: by 10.50.129.104 with SMTP id nv8mr32336434igb.45.1403588541694; Mon, 23 Jun 2014 22:42:21 -0700 (PDT) Received: from [10.0.0.119] (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id vl10sm39213083igb.16.2014.06.23.22.42.20 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 23 Jun 2014 22:42:20 -0700 (PDT) Sender: Warner Losh <wlosh@bsdimp.com> Content-Type: multipart/signed; boundary="Apple-Mail=_3AEF3E78-6AA3-4C5E-83D3-7055130C549E"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Subject: Re: Problems building FreeBSD 9.2 on FreeBSD 10 From: Warner Losh <imp@bsdimp.com> In-Reply-To: <20140624022410.GP1218@hub.FreeBSD.org> Date: Mon, 23 Jun 2014 23:42:20 -0600 Message-Id: <3DC0E4E6-A4B5-43EE-BD21-38B68DAE42F1@bsdimp.com> References: <CAG=rPVfanU=FVWPd768_G5NjXRHnUH5o05+KwFeLaTQqU3Ux8w@mail.gmail.com> <FC1B2983-4B49-4480-855E-6BD09B148F31@bsdimp.com> <CAG=rPVd5XGz8hfuBtcOuuZp8ND1ssWoTkVNn0Hg6Li_2-NrgcA@mail.gmail.com> <1ED3AC7E-0F74-46A7-BAAA-E30600DC23BB@bsdimp.com> <CAG=rPVeP32=y3VZgn0MXFPrr8tevL=jOsCow=rvpxRevmvoLqA@mail.gmail.com> <8CD24B0A-DF45-4437-BEBE-8C67B241DE93@bsdimp.com> <CAG=rPVcrJpP_1VcKZnsxAugBywJBXg63p2piX7nPndTunPEWDQ@mail.gmail.com> <2063888D-CCAE-431B-A409-F17AA4422006@bsdimp.com> <20140624011251.GN1218@hub.FreeBSD.org> <60320DD3-56C4-4922-A537-FF94C392A45A@bsdimp.com> <20140624022410.GP1218@hub.FreeBSD.org> To: Glen Barber <gjb@freebsd.org> X-Mailer: Apple Mail (2.1878.2) Cc: Craig Rodrigues <rodrigc@FreeBSD.org>, Brooks Davis <brooks@freebsd.org>, Dimitry Andric <dim@freebsd.org>, "Simon J. Gerraty" <sjg@juniper.net>, freebsd-current Current <freebsd-current@freebsd.org>, Marcel Moolenaar <marcel@freebsd.org> X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current <freebsd-current.freebsd.org> List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-current>, <mailto:freebsd-current-request@freebsd.org?subject=unsubscribe> List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current/>; List-Post: <mailto:freebsd-current@freebsd.org> List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help> List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>, <mailto:freebsd-current-request@freebsd.org?subject=subscribe> X-List-Received-Date: Tue, 24 Jun 2014 05:42:28 -0000 --Apple-Mail=_3AEF3E78-6AA3-4C5E-83D3-7055130C549E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Jun 23, 2014, at 8:24 PM, Glen Barber <gjb@freebsd.org> wrote: > On Mon, Jun 23, 2014 at 07:42:27PM -0600, Warner Losh wrote: >>=20 >> On Jun 23, 2014, at 7:12 PM, Glen Barber <gjb@FreeBSD.org> wrote: >>=20 >>> On Mon, Jun 23, 2014 at 06:57:15PM -0600, Warner Losh wrote: >>>> On Jun 23, 2014, at 6:15 PM, Craig Rodrigues <rodrigc@FreeBSD.org> = wrote: >>>>> So, I guess that stable/9 can build properly on a stable/10 box. >>>>> For FreeBSD 9.2, there is no easy way out. >>>>=20 >>>> You=92ll have to back port the patch then. We don=92t guarantee = forward >>>> compatibility like this since 9.2 is frozen in time now. >>>>=20 >>>=20 >>> I'd really like to discuss rethinking our forward-compatibility >>> policies, since we have (now) 3 active stable/ branches, plus head/.=20= >>=20 >> Generally, in the past, the rule has been =93head will build from the = last stable branch tip.=94 This was extended, for a while, to =93last = stable branch point=94 when Ruslan made sure that worked. While -stable = has generally built on -head, this was never part of the contract. It = usually did, but is very very hard to guarantee given the nature of = head=92s tools changing in ways that are allowed for head, but that = break prior branches. >>=20 >=20 > I sort of typed what I meant a bit backwards from what I intended to > write. What I meant (sort of) is, "I would like to discuss our = forward > thinking on backward-compatibility." >=20 > I fully understand forward-compatibility is not feasible. We already build current back to the stable/8 branch. 7.x is no longer = feasible, supported or tested. stable/10 is the only one that is = required, but enough people use stable/9 machines it will work. stable/8 = has one customer that is keeping it going, so I suspect it will stop = working in the coming years, maybe before 11 is branched. >>> What I would like to see, with my RE hat on, is a "best effort" >>> backwards compatibility to being able to build the lowest-numbered >>> supported stable/ branch on head/. >>=20 >> I think, that as in the past, this will generally work. However, it = won=92t always work. Things break in this area a lot. More than you = might think, especially with the huge amount of churn we=92ve had wrt = compilers, make, etc. I suspect that new imports of clang will break = this every time, since every import of clang has required changes to the = tree to either disable warnings, or to fix newly flagged things. I = suspect there will be a lot of churn here, and releases will go stale = the fastest=85 With -current starting to support building multiple = versions of clang (and gcc), there=92s hope for the future, but = back-porting this code is beyond what I have the time to do. That=92s = going to make things increasingly difficult as we march forward. >>=20 >=20 > I hate to even suggest this, but the ports tree (ab)uses the notion of > using the kern.osreldate for certain things. This, however, requires > proper bumping of __FreeBSD_version when needed, and maintenance of = the > Makefiles for the kern.osreldate-specific things. We already do that. It mostly works most of the time, so long as the = delta isn=92t too great, and we don=92t have high compiler/tools/make = velocity=85 Except we don=92t use the kernel version, but rather the = installed tools version as indicated by a .h file. That=92s more robust. > The benefit to this is that it would help prevent pissing off ports > developers and make their lives a bit easier when userland / kernel > things change. It would, however, (expectedly) is that it would force > src committers to do the right thing. Win-win, IMHO. What should we do we aren=92t doing today? >> This isn=92t even getting into cross build scenarios=85. >>=20 >> Or building releases, which is a whole different set of lightly = tested code that is mostly host independent, but sometimes isn=92t as = much as you=92d had hoped... >>=20 >>> Sure, this won't always work, but "best effort" is better than "no >>> effort", which the latter is why we do not have stable/8 snapshot >>> builds, to be honest. I won't spend the time on the = stable/8/release/ >>> code nor the snapshot build scripts to waste the time. Building >>> stable/9 on head/ is annoying alone. >>=20 >> stable/9 builds on head. If there=92s a race, that needs to be fixed = in stable/9. That=92s quasi supported because people do it. The =93best = effort=94 involves people that are interested in the bugs being fixed = fixing them, or convincing others to fix them. For me, this scenario is = outside the area I care about, have the ability to test, or have time = for. >>=20 >> So =93best effort=94 involves more than me making an effort. I may or = I may not. It all depends on my time and inclination. If it is going to = work, bugs need to be fixed in stable/9 that prevents it from building = on head, while not breaking the ability to build on 9. So there=92s a = lot of heavy lifting that will be needed in short order to keep this = working once the clang folks can figure out how to get past the angst of = the upgrade path and push forward to 3.5. Some architectures will break = when that happens, no doubt. >>=20 >=20 > Personally, and no I won't discuss more on this, I'm in the camp of "I > don't really see clang as a feature." It caused our ports developers > and maintainers a mountain of headache to convert to the "invisibly = new > great thing", it increases our overall buildworld by a = non-insignificant > amount of time, and it has personally caused me headaches (still > ongoing) trying to figure out what the correct incantation of evil to > wish over the cauldron to get BeagleBone images to build. (They're > failing because gcc is not being installed on both head/ and = stable/10/, > and despite the game of "musical KNOBS" I've been playing over the = past > few days, I'm running out of hair to pull out of my head.) Yea, if you are using crochet, that=92s because crochet uses xdev rather = than a ports compiler (which in all fairness didn=92t exist when it = started) to build u-boot, which basically requires gcc. The compiler rework in head is still a work in progress. What=92s there = now is better than before, but still isn=92t quite right. I do plan on = fixing that before summer is out. >> But 9.2 will never build on head because it is broken with bmake, = which is now standard for head. Since 9.2 cannot be changed, and since = we=92ve removed (or nearly) fmake in current, chances are quite good it = will never build on head again without some special handling. >>=20 >> In summary, good luck! there=92s a lot of use cases here, and it will = take time and effort of multiple people over the long haul to keep it = working. Best effort may be larger than you estimate=85 I won=92t stand = in your way, but I=92m afraid my time available to help is limited. >>=20 >=20 > As Ozzy once sang: >=20 > "I'm just a dreamer > I dream my life away > I'm just a dreamer > Who dreams of better days=94 Since I was commenting on the opposite problem of what you were wanting = comments on, my harshness is justified. What you want though, we largely already do, though maybe with a few = more warts than necessary (which we should try to fix). Most of the = warts are due to gcc/clang division being done badly and unsustainable = initially and the cleanup taking a bit of time, not specific version = issues. Back to your basic point, the issue becomes a testability one: not all = committers can reasonable be expected to have 8 or 9 systems to test = every change. Having a 10.x system to test changes is a bit of a stretch = as it is, but it is the official policy that many folks play fast and = loose with the rules because they haven=92t been burned too often by it=85= VMs, Jails, etc of various flavors can help, but some info does leak = through (mostly the info leaks are bugs or kludges that well meaning = people shouldn=92t have done given the historical knowledge we have = about the ill effects of certain ways to do conditional compilation). Warner --Apple-Mail=_3AEF3E78-6AA3-4C5E-83D3-7055130C549E Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJTqQ+8AAoJEGwc0Sh9sBEANF8P/j5uxOgG4T3jdXvTUDdJ2UYC b/4XXg9Wueh/kvSM1J/qkZqYj98XXUhJdg/VOLS9Zd2dOkYB3CLTudqSF8vktUWx JejMqoVvuhDIUG2PtOBEcmHJsxkx1eKmK7AcIvXV1ljKplhsBXcbNLv4ojt5hDRK h5nAWCDLDrjnQgfy0ugf1O8PKtj8ChIsoV87hMZ4giv08HoIQTmNqCHjo7NoLjT/ mL0J8seb/8r2LFrP69VBj8i6h0Bte0XxVE1/rlmtd2rpYbXJbGxTHuztXu0WiUm9 XFQ8Uuaqp1LNxCYYWCWQx3fePcLXGETkFbkq2vOCi8GfV3IXIYrfJA0R+yieoB1x JjO05bZr5KdjAIHH2W2HH0OqgVjmdL2e8pVcNlgzXGZN2veTPde10b+d7aciODrI JsAEFr4SzXuJqDmw3dJ5VCU4RJKZQduenxRQY3m1V/TAbG7kko+b9Dk0aS7o48ns la8gkAziTyf3F/mNjltkCT3VXd1fI/2T2ITHxCJYoQgrLC8NrPo12DUsv5PHsNAS 7sXEpDI2d5UadKGykus7PI9JMLtyG6TCfZ6oTbXl2B1bIRGKRHXp9bAJn3D7NgHf MuyubeRN/3xerD9VUi0mWvvYYe0xkqLPmL4ox1E1KLIAe7m93zk4zWIBnKiAvDo6 nwUzzUhhslHy7oto+U8v =V6b4 -----END PGP SIGNATURE----- --Apple-Mail=_3AEF3E78-6AA3-4C5E-83D3-7055130C549E--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAASDrVnfxR40OsJLRLQUfyzhBHuHynYAqmaq=9EBUxZHMUCYnw>