From owner-freebsd-current@freebsd.org Sun Sep 3 02:03:53 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 360FDE11AC2; Sun, 3 Sep 2017 02:03:53 +0000 (UTC) (envelope-from jmd@freebsd.org) Received: from www.poelloepaeae.de (v22017034403546374.happysrv.de [188.68.38.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 002AF7D079; Sun, 3 Sep 2017 02:03:52 +0000 (UTC) (envelope-from jmd@freebsd.org) Received: from manray.ogolem.org (c-73-195-214-55.hsd1.nj.comcast.net [73.195.214.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by www.poelloepaeae.de (Postfix) with ESMTPSA id 1649818811B; Sun, 3 Sep 2017 04:03:43 +0200 (CEST) Date: Sat, 2 Sep 2017 22:02:57 -0400 From: Johannes M Dieterich To: freebsd-current@freebsd.org, freebsd-x11@freebsd.org Subject: [RFC] future of drm1 in base Message-ID: <20170902220257.6667280e@manray.ogolem.org> X-Mailer: Claws Mail 3.15.1 (GTK+ 2.24.31; amd64-portbld-freebsd12.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Sep 2017 02:03:53 -0000 Dear current/x11, please CC me on responses. I am writing you on behalf of the FreeBSDDesktop team concerning the future of drm1 in base. drm1 in base supports the following GPUs: * 3dfx Banshee/Voodoo3+ (tdfx) * ATI Rage 128 (r128) * ATI Rage Pro (mach64) * Matrox G200/G400 (mga) * Savage3D/MX/IX, Savage4, SuperSavage, Twister, ProSavage[DDR] (savage) * SIS 300/630/540 and XGI V3XE/V5/V8 (sis) * VIA Unichrome / Pro (via) Since their original introduction up to 2010 these drivers have mostly been maintained as part of larger cleanups. The newest hardware drm1 supports dates from 2004, if I am not mistaken, and most of the hardware is AGP-based. With the introduction of graphics/drm-next-kmod which brings its own drm.ko following the Linux notation, we are facing collisions between these old drivers' drm.ko and the newer one. We would like to hear if anybody still runs CURRENT on machines housing the above GPUs and relies on drm1. If there are still a significant number of people running CURRENT on this hardware in production, we would be willing to make a graphics/drm-legacy-kmod port. Thanks, the FreeBSDDesktop team From owner-freebsd-current@freebsd.org Sun Sep 3 05:31:28 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F32B7E1BEFF; Sun, 3 Sep 2017 05:31:28 +0000 (UTC) (envelope-from cy.schubert@komquats.com) Received: from smtp-out-no.shaw.ca (smtp-out-no.shaw.ca [64.59.134.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B540B8318B; Sun, 3 Sep 2017 05:31:28 +0000 (UTC) (envelope-from cy.schubert@komquats.com) Received: from spqr.komquats.com ([96.50.22.10]) by shaw.ca with SMTP id oNVEdmAbaM9gtoNVFdU9Mj; Sat, 02 Sep 2017 23:31:26 -0600 X-Authority-Analysis: v=2.2 cv=a+JAzQaF c=1 sm=1 tr=0 a=jvE2nwUzI0ECrNeyr98KWA==:117 a=jvE2nwUzI0ECrNeyr98KWA==:17 a=kj9zAlcOel0A:10 a=2JCJgTwv5E4A:10 a=aJEGARJCAAAA:8 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8 a=hD4YFKEdfaGV2w1d5Q4A:9 a=YCkxdLnJGCefvND9:21 a=bWC31ir8Lyx8WDP3:21 a=CjuIK1q_8ugA:10 a=69xMm2rMUJ9FuF5TBKAH:22 a=Ia-lj3WSrqcvXOmTRaiG:22 a=IjZwj45LgO3ly-622nXo:22 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTPS id 22BBA1194; Sat, 2 Sep 2017 22:31:24 -0700 (PDT) Received: from slippy (localhost [127.0.0.1]) by slippy.cwsent.com (8.15.2/8.15.2) with ESMTP id v835VNEt023765; Sat, 2 Sep 2017 22:31:24 -0700 (PDT) (envelope-from Cy.Schubert@cschubert.com) Message-Id: <201709030531.v835VNEt023765@slippy.cwsent.com> X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.6 Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: Johannes M Dieterich cc: freebsd-current@freebsd.org, freebsd-x11@freebsd.org Subject: Re: [RFC] future of drm1 in base In-Reply-To: Message from Johannes M Dieterich of "Sat, 02 Sep 2017 22:02:57 -0400." <20170902220257.6667280e@manray.ogolem.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 02 Sep 2017 22:31:23 -0700 X-CMAE-Envelope: MS4wfNELgRgbWAzitOM/ygoj3CitBQb9a+ePwQStIXRizhyU/Lhtrb95HCPTEWvT3DOERnwMUjjXaKWBHZ0Dd306/ov6yelqvCKReNOW2eachikjB6nvQqvs NrbsGJIMUjRGv2eqEuSilHmZE9stX8EHShfSuctNyJLTAptlhzKQsfjY21kXj7AgNfC9iMkJDArnjKm2m9uX+Z3KU921aOewj8M+RGOAe87dHFWXcb+H8tuY g87Aam3zyHMMEGeeIp4WWA== X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Sep 2017 05:31:29 -0000 In message <20170902220257.6667280e@manray.ogolem.org>, Johannes M Dieterich wr ites: > Dear current/x11, > > please CC me on responses. > > I am writing you on behalf of the FreeBSDDesktop team concerning the > future of drm1 in base. > > drm1 in base supports the following GPUs: > * 3dfx Banshee/Voodoo3+ (tdfx) > * ATI Rage 128 (r128) > * ATI Rage Pro (mach64) > * Matrox G200/G400 (mga) > * Savage3D/MX/IX, Savage4, SuperSavage, Twister, ProSavage[DDR] (savage) > * SIS 300/630/540 and XGI V3XE/V5/V8 (sis) > * VIA Unichrome / Pro (via) > > Since their original introduction up to 2010 these drivers have mostly > been maintained as part of larger cleanups. The newest hardware drm1 > supports dates from 2004, if I am not mistaken, and most of the > hardware is AGP-based. > > With the introduction of graphics/drm-next-kmod which brings its own > drm.ko following the Linux notation, we are facing collisions between > these old drivers' drm.ko and the newer one. > > We would like to hear if anybody still runs CURRENT on machines housing > the above GPUs and relies on drm1. > > If there are still a significant number of people running CURRENT on > this hardware in production, we would be willing to make a > graphics/drm-legacy-kmod port. Thanks for the heads up Johannes. I currently have three machines that each run ATI r128, mach64 and the last one an mga card. I normally use my i945 and i915 laptops (mostly the former) but on occasion I may fire up X on one of the other three. Having a drm-legacy port in the tree would benefit to me. -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. From owner-freebsd-current@freebsd.org Sun Sep 3 10:02:16 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 04CF8E033F5; Sun, 3 Sep 2017 10:02:16 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from theravensnest.org (xvm-110-62.dc2.ghst.net [46.226.110.62]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "theravensnest.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9DEC265C97; Sun, 3 Sep 2017 10:02:14 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from [192.168.1.65] (host86-138-54-151.range86-138.btcentralplus.com [86.138.54.151]) (authenticated bits=0) by theravensnest.org (8.15.2/8.15.2) with ESMTPSA id v83A2A1Q057278 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 3 Sep 2017 10:02:11 GMT (envelope-from theraven@FreeBSD.org) X-Authentication-Warning: d60e724c-75b0-4b63-9702-f4a9d2bf6793: Host host86-138-54-151.range86-138.btcentralplus.com [86.138.54.151] claimed to be [192.168.1.65] Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: [RFC] future of drm1 in base From: David Chisnall In-Reply-To: <201709030531.v835VNEt023765@slippy.cwsent.com> Date: Sun, 3 Sep 2017 11:02:07 +0100 Cc: Johannes M Dieterich , freebsd-current@freebsd.org, freebsd-x11@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <288500A4-AF22-465D-AAE7-794BEED3A5E5@FreeBSD.org> References: <201709030531.v835VNEt023765@slippy.cwsent.com> To: Cy Schubert X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Sep 2017 10:02:16 -0000 On 3 Sep 2017, at 06:31, Cy Schubert wrote: >=20 > Thanks for the heads up Johannes. I currently have three machines that = each=20 > run ATI r128, mach64 and the last one an mga card. I normally use my = i945=20 > and i915 laptops (mostly the former) but on occasion I may fire up X = on one=20 > of the other three. Having a drm-legacy port in the tree would benefit = to=20 > me. It=E2=80=99s been quite a while since I used any of these (though much = of the list is very familiar), but the last machine I ran with a mach64 = card was faster with the vesa driver than with the =E2=80=98accelerated=E2= =80=99 driver (as I recall, it was a 500MHz Pentium III). I suspect the = real question is not whether people have machines that use these cards, = but whether they do anything with them where they=E2=80=99d notice the = lack of acceleration. David From owner-freebsd-current@freebsd.org Sun Sep 3 10:28:11 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5330DE04299; Sun, 3 Sep 2017 10:28:11 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: from mail-vk0-x22c.google.com (mail-vk0-x22c.google.com [IPv6:2607:f8b0:400c:c05::22c]) (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 05948666B6; Sun, 3 Sep 2017 10:28:11 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: by mail-vk0-x22c.google.com with SMTP id q189so8970477vke.4; Sun, 03 Sep 2017 03:28:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6TStfYTNtyXqrabEpHMG4dOT88yHKwdvnlv1uIMu91M=; b=HYOCcnbIR/a2qHSSYHXHYUbkJr4HgYLHpyBiTJd8p/s1nMdKyRYnhri6/xH4Ujhkjw IVAcGfcR9CzKMnl6xM3rveeTudKKBHfl0REhxe9hl484HiCmqkbbchgbo7XwTquXMU9Q +DGKCAANdmTWqONdi+JHHR7vu6nRNvgcpoigimPnRVYON8FvbakhuXDTQIeZhopjggIF rVKDn/Fdh9v/sZK5ySaV4Znh+w7iB1sj+jnReKLEY2ArqN8dpYvtQdZI8YNrAxSkoeD+ Fs1rDTJImy9fOFNbSfi2Vu9e694WL/dUoiSwn6zyyzNrgUP/HDERgGVVdPDZwsEGuI3B wuZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=6TStfYTNtyXqrabEpHMG4dOT88yHKwdvnlv1uIMu91M=; b=SKiV6vEcYaAp3Ux6NgNvq+j7BfoUyHR/7sabHv0esnegp3iKL5EkckNOH5UHdYStOg /CvqAUtdAQ81JCvPLZPJK29KsEkSf8+dMygzCMCpw7XB67jtSGvCrqpLE4NAS7Dt56BH JJzn3qjOEouz947se0aOOmCTbhTPvAFg3/jShaL9mD4jd02P1S28XaJWSHb1IcZwx//j sWqW2hjETE7zWSw9F0yecgWSvOSc4//HCUdxeH5Gg/uS/dj3WcLnYl5krLDQK21Slmqv elElxciJZ+RKaE1zdB9O1Q3SfdzQFGzJjCVjv1zguQh1gyGGVUmAYooKsd9G8FrR24xY bGhA== X-Gm-Message-State: AHPjjUjl17KOYZ/2uJgRAEvjPhEsGgYgtk5hIfPbcMxySsmFsjvBvzro kTriCfAOZHvpJVbKb8s2sqzXbX3uLw== X-Google-Smtp-Source: ADKCNb4tREqurrdkwuOCEWnAC/Qm/KmyDcFKfoxZYhriy3NxhXoseqGGPT36Ho6ElBN4hBI+tcqNs8O9cuXJZx4hRho= X-Received: by 10.31.192.133 with SMTP id q127mr4456830vkf.20.1504434489721; Sun, 03 Sep 2017 03:28:09 -0700 (PDT) MIME-Version: 1.0 References: <201709030531.v835VNEt023765@slippy.cwsent.com> <288500A4-AF22-465D-AAE7-794BEED3A5E5@FreeBSD.org> In-Reply-To: <288500A4-AF22-465D-AAE7-794BEED3A5E5@FreeBSD.org> From: blubee blubeeme Date: Sun, 03 Sep 2017 10:27:58 +0000 Message-ID: Subject: Re: [RFC] future of drm1 in base To: David Chisnall , Cy Schubert Cc: freebsd-x11@freebsd.org, Johannes M Dieterich , freebsd-current@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Sep 2017 10:28:11 -0000 I also have a current machine with one of those listed gpu. A friend got hacked on windows, I got them setup with a ryzen chip and no integrated GPU. Finding a supported gpu was a challenge but, those old drivers allow the machine to have display. Please try to maintain the older drivers, thanks. Best, Owen On Sun, Sep 3, 2017, 18:03 David Chisnall wrote: > On 3 Sep 2017, at 06:31, Cy Schubert wrote: > > > > Thanks for the heads up Johannes. I currently have three machines that > each > > run ATI r128, mach64 and the last one an mga card. I normally use my i9= 45 > > and i915 laptops (mostly the former) but on occasion I may fire up X on > one > > of the other three. Having a drm-legacy port in the tree would benefit = to > > me. > > It=E2=80=99s been quite a while since I used any of these (though much of= the list > is very familiar), but the last machine I ran with a mach64 card was fast= er > with the vesa driver than with the =E2=80=98accelerated=E2=80=99 driver (= as I recall, it > was a 500MHz Pentium III). I suspect the real question is not whether > people have machines that use these cards, but whether they do anything > with them where they=E2=80=99d notice the lack of acceleration. > > David > > _______________________________________________ > freebsd-x11@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-x11 > To unsubscribe, send any mail to "freebsd-x11-unsubscribe@freebsd.org" From owner-freebsd-current@freebsd.org Sun Sep 3 14:49:03 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D14B3E0EE70; Sun, 3 Sep 2017 14:49:03 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 903286DEB1; Sun, 3 Sep 2017 14:49:03 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1doVj1-000Fzk-G0; Sun, 03 Sep 2017 17:18:11 +0300 Date: Sun, 3 Sep 2017 17:18:11 +0300 From: Slawa Olhovchenkov To: Johannes M Dieterich Cc: freebsd-current@freebsd.org, freebsd-x11@freebsd.org Subject: Re: [RFC] future of drm1 in base Message-ID: <20170903141811.GB9110@zxy.spb.ru> References: <20170902220257.6667280e@manray.ogolem.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170902220257.6667280e@manray.ogolem.org> User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Sep 2017 14:49:03 -0000 On Sat, Sep 02, 2017 at 10:02:57PM -0400, Johannes M Dieterich wrote: > Dear current/x11, > > please CC me on responses. > > I am writing you on behalf of the FreeBSDDesktop team concerning the > future of drm1 in base. > > drm1 in base supports the following GPUs: > * 3dfx Banshee/Voodoo3+ (tdfx) > * ATI Rage 128 (r128) > * ATI Rage Pro (mach64) > * Matrox G200/G400 (mga) > * Savage3D/MX/IX, Savage4, SuperSavage, Twister, ProSavage[DDR] (savage) > * SIS 300/630/540 and XGI V3XE/V5/V8 (sis) > * VIA Unichrome / Pro (via) > > Since their original introduction up to 2010 these drivers have mostly > been maintained as part of larger cleanups. The newest hardware drm1 > supports dates from 2004, if I am not mistaken, and most of the > hardware is AGP-based. Some of this hardware is part of more modern servers platforms (ex: http://www.supermicro.com/products/motherboard/Xeon/C600/X9DRT-F.cfm) > With the introduction of graphics/drm-next-kmod which brings its own > drm.ko following the Linux notation, we are facing collisions between > these old drivers' drm.ko and the newer one. > > We would like to hear if anybody still runs CURRENT on machines housing > the above GPUs and relies on drm1. > > If there are still a significant number of people running CURRENT on > this hardware in production, we would be willing to make a > graphics/drm-legacy-kmod port. > > Thanks, > > the FreeBSDDesktop team > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@freebsd.org Sun Sep 3 16:51:13 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A2BFFE142F8; Sun, 3 Sep 2017 16:51:13 +0000 (UTC) (envelope-from cy.schubert@komquats.com) Received: from smtp-out-no.shaw.ca (smtp-out-no.shaw.ca [64.59.134.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 564F17190A; Sun, 3 Sep 2017 16:51:12 +0000 (UTC) (envelope-from cy.schubert@komquats.com) Received: from spqr.komquats.com ([96.50.22.10]) by shaw.ca with SMTP id oY6ydnzrdM9gtoY6zdUysN; Sun, 03 Sep 2017 10:51:06 -0600 X-Authority-Analysis: v=2.2 cv=a+JAzQaF c=1 sm=1 tr=0 a=jvE2nwUzI0ECrNeyr98KWA==:117 a=jvE2nwUzI0ECrNeyr98KWA==:17 a=kj9zAlcOel0A:10 a=2JCJgTwv5E4A:10 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8 a=BWvPGDcYAAAA:8 a=NEHEcJ74qUXLnIKBCx0A:9 a=CjuIK1q_8ugA:10 a=Ia-lj3WSrqcvXOmTRaiG:22 a=IjZwj45LgO3ly-622nXo:22 a=pxhY87DP9d2VeQe4joPk:22 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTPS id 3FB5C1742; Sun, 3 Sep 2017 09:51:04 -0700 (PDT) Received: from slippy (localhost [127.0.0.1]) by slippy.cwsent.com (8.15.2/8.15.2) with ESMTP id v83Gp3He026291; Sun, 3 Sep 2017 09:51:04 -0700 (PDT) (envelope-from Cy.Schubert@cschubert.com) Message-Id: <201709031651.v83Gp3He026291@slippy.cwsent.com> X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.6 Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: blubee blubeeme cc: David Chisnall , Cy Schubert , freebsd-x11@freebsd.org, Johannes M Dieterich , freebsd-current@freebsd.org Subject: Re: [RFC] future of drm1 in base In-Reply-To: Message from blubee blubeeme of "Sun, 03 Sep 2017 10:27:58 -0000." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 03 Sep 2017 09:51:03 -0700 X-CMAE-Envelope: MS4wfGPeba3LhtkOZKCoFtWlnC2USMORDJoe/l1tlJpsW80qj3LI2hvHgHYQ6y4UqyekMwzXc46Yse2rSbu27KIN6z7grWjBSAgqRjSafYumSMr5vnI6+W8c ZimNEJne70Cl7K/1LgSG/IYhIIGMglr2WOtOCX9BFJr1PUDvVAsfmQhacZanYIWfv0lkTNHZUU9jPh5vxE2e+IZCkyD8c9Ux7Xs+rSWsafjL0lr20d+3RDpb HXVxIZSmzE2M3UJIiSDWpCwdMbs0WYzW7hdIyS5rnxSThvV9tpA8k6OVDnYCMG5hsYLYWJo2UZ8OqUxfJXCWvA== X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Sep 2017 16:51:13 -0000 (Replying inline) In message , blubee blubeeme writes: > I also have a current machine with one of those listed gpu. > > A friend got hacked on windows, I got them setup with a ryzen chip and no > integrated GPU. Finding a supported gpu was a challenge but, those old > drivers allow the machine to have display. > > Please try to maintain the older drivers, thanks. > > Best, > Owen I wouldn't mind taking care of and feeding the new port if it's created. -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. > > On Sun, Sep 3, 2017, 18:03 David Chisnall wrote: > > > On 3 Sep 2017, at 06:31, Cy Schubert wrote: > > > > > > Thanks for the heads up Johannes. I currently have three machines that > > each > > > run ATI r128, mach64 and the last one an mga card. I normally use my i9= > 45 > > > and i915 laptops (mostly the former) but on occasion I may fire up X on > > one > > > of the other three. Having a drm-legacy port in the tree would benefit = > to > > > me. > > > > It=E2=80=99s been quite a while since I used any of these (though much of= > the list > > is very familiar), but the last machine I ran with a mach64 card was fast= > er > > with the vesa driver than with the =E2=80=98accelerated=E2=80=99 driver (= > as I recall, it > > was a 500MHz Pentium III). I suspect the real question is not whether > > people have machines that use these cards, but whether they do anything > > with them where they=E2=80=99d notice the lack of acceleration. > > > > David > > > > _______________________________________________ > > freebsd-x11@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-x11 > > To unsubscribe, send any mail to "freebsd-x11-unsubscribe@freebsd.org" From owner-freebsd-current@freebsd.org Sun Sep 3 17:38:29 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0224CE16389; Sun, 3 Sep 2017 17:38:29 +0000 (UTC) (envelope-from jmd@freebsd.org) Received: from www.poelloepaeae.de (v22017034403546374.happysrv.de [188.68.38.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BECD672D8F; Sun, 3 Sep 2017 17:38:28 +0000 (UTC) (envelope-from jmd@freebsd.org) Received: from manray.ogolem.org (c-73-195-214-55.hsd1.nj.comcast.net [73.195.214.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by www.poelloepaeae.de (Postfix) with ESMTPSA id 2172A18811B; Sun, 3 Sep 2017 19:00:21 +0200 (CEST) Date: Sun, 3 Sep 2017 13:00:17 -0400 From: Johannes M Dieterich To: Cy Schubert Cc: blubee blubeeme , David Chisnall , freebsd-x11@freebsd.org, freebsd-current@freebsd.org Subject: Re: [RFC] future of drm1 in base Message-ID: <20170903130017.0a5fdc36@manray.ogolem.org> In-Reply-To: <201709031651.v83Gp3He026291@slippy.cwsent.com> References: <201709031651.v83Gp3He026291@slippy.cwsent.com> X-Mailer: Claws Mail 3.15.1 (GTK+ 2.24.31; amd64-portbld-freebsd12.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Sep 2017 17:38:29 -0000 On Sun, 03 Sep 2017 09:51:03 -0700 Cy Schubert wrote: > (Replying inline) > In message > om> > , blubee blubeeme writes: > > I also have a current machine with one of those listed gpu. > > > > A friend got hacked on windows, I got them setup with a ryzen chip > > and no integrated GPU. Finding a supported gpu was a challenge but, > > those old drivers allow the machine to have display. > > > > Please try to maintain the older drivers, thanks. Well, from now on you can recommend also AMD Tahiti up to Polaris alongside the binary Nvidia driver, assuming the system is amd64. :-) > > I wouldn't mind taking care of and feeding the new port if it's > created. Thank you! It does look to me that there is a need for continued support to exist. So we will create a port now and then I will propose removal of drm1 from base so that users of graphics/drm-next-kmod and graphics/drm-legacy-kmod can more easily co-exist in the future. I will probably issue a CFT after the port landed to make sure that everything still works and would much appreciate if people with the hardware could give it a spin. Thank you everybody for your responses! Johannes From owner-freebsd-current@freebsd.org Sun Sep 3 19:19:24 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 07D35E1A62E; Sun, 3 Sep 2017 19:19:24 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::22f]) (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 C0D7375519; Sun, 3 Sep 2017 19:19:23 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-it0-x22f.google.com with SMTP id c13so10489012itb.0; Sun, 03 Sep 2017 12:19:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=msNQYTKY4ujbE+jwWPbaNgw4jChew9FuUHAko8MnNBk=; b=RHgPdBGUszZm+xT3LzqSLDlV7aBHOTOa6XM85+pFj/r8cf9Diwsm48GkaLDeNU2OLq t/ZNU+xVbHLjysUcOXnfyiSS0AHJuCJDFCU4pvUbGcKtU052pTaVp9YpxD50cxY02FbI 22XrcjQkqQ1H742f1gY0tuUB6PHc6J5SG0aH/GB+l1asXjL6ihyc0RYva2LvJsV7Xx0e 6Ia8St2S7vz4sIEGay03Ml0Hx0ejeE9IwMV4xBHbwhqGOUEy2V0U5d9lr/LA4rccgps/ Nrp0yQ5ue6F9tC8nCrv2rOe5bu66vYTCWDybixp1e3S8WyGq+s3Q+lE9gwJe/BHqZtmK bAkA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to:user-agent; bh=msNQYTKY4ujbE+jwWPbaNgw4jChew9FuUHAko8MnNBk=; b=CCaYlt73ubS9uYg+KbnmROKNYf4cmxTQswORIz9OnX4VjPZMTvyzTt3ERUzZqImnu4 ExQ7JhVrS6hSdMe0R+K9J65cC5UwhrSd788LQwaeLaX6j64v65vfcvJCRWUwQiIupSwP 4fa+f3bibyRF984gmZMP01fJA0gySP1mD3wHYdvhx63sMdlj4cW3OdsOS5I7g2C2jLvv XUufN2+0VRISbuTtMdwHYgPqvnN+K7CPV99WsQ+UGNehijzVSDh1ANyplWz1+aEsvPVq ibXu1Snm0VDcBegM5GxtWUk8hET3MvWf5Dhx07su8N3I1QVcGpJoq+n763YdsdRqZ1p/ yUwg== X-Gm-Message-State: AHPjjUizHVBsIuVC+TlkQPvgAaiiZQwYT471ep+S431KxjLGU5Z9R2FD Id4mQUH5CwpbAlxZ X-Google-Smtp-Source: ADKCNb7uJ5LSBGrjzgdEZ/v6cFZnnpFAqyfhZdbWwDR/UdmtQFZYUdzfpKuePFjWk7aoik0+pS+ErQ== X-Received: by 10.36.144.195 with SMTP id x186mr5169309itd.5.1504466362750; Sun, 03 Sep 2017 12:19:22 -0700 (PDT) Received: from bish ([75.98.19.132]) by smtp.gmail.com with ESMTPSA id b66sm2587447itb.0.2017.09.03.12.19.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 03 Sep 2017 12:19:21 -0700 (PDT) Sender: Mark Johnston Date: Sun, 3 Sep 2017 12:19:09 -0700 From: Mark Johnston To: Johannes M Dieterich Cc: freebsd-current@freebsd.org, freebsd-x11@freebsd.org Subject: Re: [RFC] future of drm1 in base Message-ID: <20170903191908.GA1259@bish> References: <20170902220257.6667280e@manray.ogolem.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170902220257.6667280e@manray.ogolem.org> User-Agent: Mutt/1.8.3 (2017-05-23) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Sep 2017 19:19:24 -0000 On Sat, Sep 02, 2017 at 10:02:57PM -0400, Johannes M Dieterich wrote: > Dear current/x11, > > please CC me on responses. > > I am writing you on behalf of the FreeBSDDesktop team concerning the > future of drm1 in base. > > drm1 in base supports the following GPUs: > * 3dfx Banshee/Voodoo3+ (tdfx) > * ATI Rage 128 (r128) > * ATI Rage Pro (mach64) > * Matrox G200/G400 (mga) > * Savage3D/MX/IX, Savage4, SuperSavage, Twister, ProSavage[DDR] (savage) > * SIS 300/630/540 and XGI V3XE/V5/V8 (sis) > * VIA Unichrome / Pro (via) > > Since their original introduction up to 2010 these drivers have mostly > been maintained as part of larger cleanups. The newest hardware drm1 > supports dates from 2004, if I am not mistaken, and most of the > hardware is AGP-based. > > With the introduction of graphics/drm-next-kmod which brings its own > drm.ko following the Linux notation, we are facing collisions between > these old drivers' drm.ko and the newer one. I don't think this is a real problem. The reason one currently needs to manually load the drm-next drm.ko (rather than just kldloading a driver and having it pick up the right drm.ko automatically) is that our drm.ko defines the same module ("drmn") as drm2.ko in the base system. So upon attempting to load a drm-next driver, the kernel uses the linker hints to load drm2.ko, which is incorrect. However, this can be addressed by simply bumping the drmn version in the port and modifying the drivers accordingly. I've submitted a 4-line PR which does exactly that. After that change, we can modify the pkg-message to omit drm.ko from the kld_list value. As a result, the name of our DRM module doesn't matter since users don't need to specify it, so the collision with drm1 isn't a problem. > We would like to hear if anybody still runs CURRENT on machines housing > the above GPUs and relies on drm1. > > If there are still a significant number of people running CURRENT on > this hardware in production, we would be willing to make a > graphics/drm-legacy-kmod port. With the PR I mentioned above, I think it's a non-issue to keep drm1 in the base system. Since there appear to be at least some users of those drivers, I really think it would be preferable to avoid removing them unless it's absolutely necessary. From owner-freebsd-current@freebsd.org Mon Sep 4 19:58:44 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F3421E1AB51; Mon, 4 Sep 2017 19:58:44 +0000 (UTC) (envelope-from jmd@freebsd.org) Received: from www.poelloepaeae.de (v22017034403546374.happysrv.de [188.68.38.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BC3A28367E; Mon, 4 Sep 2017 19:58:44 +0000 (UTC) (envelope-from jmd@freebsd.org) Received: from mailman (www.poelloepaeae.de [192.168.1.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by www.poelloepaeae.de (Postfix) with ESMTPSA id D893D18811D; Mon, 4 Sep 2017 21:33:37 +0200 (CEST) From: Johannes M Dieterich To: Mark Johnston Cc: freebsd-current@freebsd.org, freebsd-x11@freebsd.org Subject: Re: [RFC] future of drm1 in base In-Reply-To: <20170903191908.GA1259@bish> Message-ID: <20170904193337.Horde.Wm3jEJaHwm_CuvGbAmSToz8@www.poelloepaeae.de> User-Agent: Horde Application Framework 5 Date: Mon, 04 Sep 2017 19:33:37 +0000 Content-Type: text/plain; charset=utf-8 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Sep 2017 19:58:45 -0000 Mark Johnston – Sun., 3. September 2017 15:19 > On Sat, Sep 02, 2017 at 10:02:57PM -0400, Johannes M Dieterich wrote: > > Dear current/x11, > > > > please CC me on responses. > > > > I am writing you on behalf of the FreeBSDDesktop team concerning the > > future of drm1 in base. > > > > drm1 in base supports the following GPUs: > > * 3dfx Banshee/Voodoo3+ (tdfx) > > * ATI Rage 128 (r128) > > * ATI Rage Pro (mach64) > > * Matrox G200/G400 (mga) > > * Savage3D/MX/IX, Savage4, SuperSavage, Twister, ProSavage[DDR] (savage) > > * SIS 300/630/540 and XGI V3XE/V5/V8 (sis) > > * VIA Unichrome / Pro (via) > > > > Since their original introduction up to 2010 these drivers have mostly > > been maintained as part of larger cleanups. The newest hardware drm1 > > supports dates from 2004, if I am not mistaken, and most of the > > hardware is AGP-based. > > > > With the introduction of graphics/drm-next-kmod which brings its own > > drm.ko following the Linux notation, we are facing collisions between > > these old drivers' drm.ko and the newer one. > > I don't think this is a real problem. The reason one currently needs to > manually load the drm-next drm.ko (rather than just kldloading a driver > and having it pick up the right drm.ko automatically) is that our drm.ko > defines the same module ("drmn") as drm2.ko in the base system. So upon > attempting to load a drm-next driver, the kernel uses the linker hints > to load drm2.ko, which is incorrect. However, this can be addressed by > simply bumping the drmn version in the port and modifying the drivers > accordingly. I've submitted a 4-line PR which does exactly that. After > that change, we can modify the pkg-message to omit drm.ko from the > kld_list value. As a result, the name of our DRM module doesn't matter > since users don't need to specify it, so the collision with drm1 isn't a > problem. > > > We would like to hear if anybody still runs CURRENT on machines housing > > the above GPUs and relies on drm1. > > > > If there are still a significant number of people running CURRENT on > > this hardware in production, we would be willing to make a > > graphics/drm-legacy-kmod port. > > With the PR I mentioned above, I think it's a non-issue to keep drm1 in > the base system. Since there appear to be at least some users of those > drivers, I really think it would be preferable to avoid removing them > unless it's absolutely necessary. Your proposed solution does work, thanks for providing it! Let's move this conversation to a later point in time then. Johannes From owner-freebsd-current@freebsd.org Mon Sep 4 20:28:40 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 209EBE1C351 for ; Mon, 4 Sep 2017 20:28:40 +0000 (UTC) (envelope-from kevin.bowling@kev009.com) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (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 E61ABBD8 for ; Mon, 4 Sep 2017 20:28:39 +0000 (UTC) (envelope-from kevin.bowling@kev009.com) Received: by mail-oi0-x22b.google.com with SMTP id x184so11078084oia.0 for ; Mon, 04 Sep 2017 13:28:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kev009.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Jgay9rPnO14HSQ/WcPJ0NQaldbigf9JJtO2gDZjZDRY=; b=pYWVNPXQUIE90HlnKWc4s3lqgM8Z62h07qo6zD8DKGXvQ3cOgHDSIURmBiXdcoMh6g tqkhsP5iebATdE0hzPBQPik8dlBMEnYUdoHBlVYtlJymo1APD84oS+VadM/HdnbKHH0g PO2qrsW7WKyB2tdq99mwXOvn74HdBnraqwyJE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=Jgay9rPnO14HSQ/WcPJ0NQaldbigf9JJtO2gDZjZDRY=; b=pBKOPSx4dhKTCdhsthENmJml70ZGNGeRq6eU9p22fkf8VR/n/WVOXhqWJYi9Y6Jacf /clUA0DUuKQ6x4qtuf2n1Y99D6sil/6quPhKgGvU65218vYjDMh9r4rgtxVR2AN/+Jkh XP9QisoEHjMQk1QklNDcl+AZPFCqf48EqgXNspJXvNMD7iWBLTWSP7jDnRclk2wYsnQ3 GB58EB6I9SdQ2uZkyvjbXsVaIvnaOTXSK1BcSRWbDapvDDBNVKQRx2RtRViqGUcUtcJP QzGX3Q/fcm4zTz3ny01jPk6q5Sg/LTcp2fjzN+vxdkn3onE/GeeQgVRDOD8t+0VKapM9 xktQ== X-Gm-Message-State: AHPjjUgGfPqmx1ZA8mGj/6oSJFtTTg3Se0AhAybMwa8Gnrezd/W/0zpu AmKP5ztp5piRHMMZQ6SoQ/Off4sbTdng X-Google-Smtp-Source: ADKCNb73R9JyFWWdScV0BQTT6Kg9BEYiFz2K1kGcNSpXwUzv30RhHXVdvnQQoylY9z7rJYK3UJhe4sDWL9ZtyF80yHU= X-Received: by 10.202.85.19 with SMTP id j19mr1406865oib.197.1504556918925; Mon, 04 Sep 2017 13:28:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.57.165 with HTTP; Mon, 4 Sep 2017 13:28:38 -0700 (PDT) In-Reply-To: <20170904193337.Horde.Wm3jEJaHwm_CuvGbAmSToz8@www.poelloepaeae.de> References: <20170903191908.GA1259@bish> <20170904193337.Horde.Wm3jEJaHwm_CuvGbAmSToz8@www.poelloepaeae.de> From: Kevin Bowling Date: Mon, 4 Sep 2017 13:28:38 -0700 Message-ID: Subject: Re: [RFC] future of drm1 in base To: Johannes M Dieterich Cc: Mark Johnston , freebsd-x11@freebsd.org, freebsd-current@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Sep 2017 20:28:40 -0000 I wasn't subscribed to -x11 earlier but do want to add some commentary to this thread. The language describing these drivers in upstream is not at all ambiguous WRT to how bad these are and Linux distributions have dropped them: menuconfig DRM_LEGACY bool "Enable legacy drivers (DANGEROUS)" depends on DRM && MMU select DRM_VM help Enable legacy DRI1 drivers. Those drivers expose unsafe and dangerous APIs to user-space, which can be used to circumvent access restrictions and other security measures. For backwards compatibility those drivers are still available, but their use is highly inadvisable and might harm your system. You are recommended to use the safe modeset-only drivers instead, and perform 3D emulation in user-space. Unless you have strong reasons to go rogue, say "N". There seems to be some kind of misunderstanding that removing these drivers is taking something away from users. I disagree. It does _not_ deorbit HW support. We'd be giving users a supportable and secure experience by dropping them. For 2d desktop it is likely that a framebuffer is fast(er) as David states. On any reasonable CPU 3d (like the server models people pointed out) may even be faster using llvmpipe. Regards, On Mon, Sep 4, 2017 at 12:33 PM, Johannes M Dieterich wro= te: > > > > Mark Johnston =E2=80=93 Sun., 3. September 2017 15:19 >> On Sat, Sep 02, 2017 at 10:02:57PM -0400, Johannes M Dieterich wrote: >> > Dear current/x11, >> > >> > please CC me on responses. >> > >> > I am writing you on behalf of the FreeBSDDesktop team concerning the >> > future of drm1 in base. >> > >> > drm1 in base supports the following GPUs: >> > * 3dfx Banshee/Voodoo3+ (tdfx) >> > * ATI Rage 128 (r128) >> > * ATI Rage Pro (mach64) >> > * Matrox G200/G400 (mga) >> > * Savage3D/MX/IX, Savage4, SuperSavage, Twister, ProSavage[DDR] (savag= e) >> > * SIS 300/630/540 and XGI V3XE/V5/V8 (sis) >> > * VIA Unichrome / Pro (via) >> > >> > Since their original introduction up to 2010 these drivers have mostly >> > been maintained as part of larger cleanups. The newest hardware drm1 >> > supports dates from 2004, if I am not mistaken, and most of the >> > hardware is AGP-based. >> > >> > With the introduction of graphics/drm-next-kmod which brings its own >> > drm.ko following the Linux notation, we are facing collisions between >> > these old drivers' drm.ko and the newer one. >> >> I don't think this is a real problem. The reason one currently needs to >> manually load the drm-next drm.ko (rather than just kldloading a driver >> and having it pick up the right drm.ko automatically) is that our drm.ko >> defines the same module ("drmn") as drm2.ko in the base system. So upon >> attempting to load a drm-next driver, the kernel uses the linker hints >> to load drm2.ko, which is incorrect. However, this can be addressed by >> simply bumping the drmn version in the port and modifying the drivers >> accordingly. I've submitted a 4-line PR which does exactly that. After >> that change, we can modify the pkg-message to omit drm.ko from the >> kld_list value. As a result, the name of our DRM module doesn't matter >> since users don't need to specify it, so the collision with drm1 isn't a >> problem. >> >> > We would like to hear if anybody still runs CURRENT on machines housin= g >> > the above GPUs and relies on drm1. >> > >> > If there are still a significant number of people running CURRENT on >> > this hardware in production, we would be willing to make a >> > graphics/drm-legacy-kmod port. >> >> With the PR I mentioned above, I think it's a non-issue to keep drm1 in >> the base system. Since there appear to be at least some users of those >> drivers, I really think it would be preferable to avoid removing them >> unless it's absolutely necessary. > Your proposed solution does work, thanks for providing it! Let's move thi= s conversation to a later point in time then. > > Johannes > _______________________________________________ > freebsd-x11@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-x11 > To unsubscribe, send any mail to "freebsd-x11-unsubscribe@freebsd.org" From owner-freebsd-current@freebsd.org Mon Sep 4 20:53:11 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D6712E1DA9F; Mon, 4 Sep 2017 20:53:11 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (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 98B0E1D0C; Mon, 4 Sep 2017 20:53:11 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-io0-x22f.google.com with SMTP id z67so5640028iof.3; Mon, 04 Sep 2017 13:53:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=x3FuVoRomfXfMTx0Kdj4d6KdRhMyZ4SennDXdq/2Lis=; b=B5OrUJE0yINFmh0cmIfbG+GkluLC8dAzKLx9M5+Y3yEiqPsdcDmh0ub4CGPlo3leoo 1kXPZhdRQfUSgG9RD7AGGeWvRxmsGReh7b2it/71ikzFD5RRmzWCzloz8gM6+vNdObju TTHbC432gDRMMI8PfcyMnKavNCCTCpXPT1z8Imw37SrZA4h6Txz3SdG5ZZ1bBVTJLpk9 KY4Ov1cGYLnM5wSU+eQQp8eJxAXWCYmMMYiyjnZyXG/97mvv3FhI43pbeRyWvln66Fhk bLEaQtgsODbTjAyTCuzhd+7sBrtLQkPr4ekPBgUvSD8jHNEBQxueKkSwhn2dcETiMB6R d4YQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=x3FuVoRomfXfMTx0Kdj4d6KdRhMyZ4SennDXdq/2Lis=; b=rnNdCrH3xZo41qWtQKV9Oq7XHE2+IqNN6bmWa1y2T1crOpUNAt8MNTfuosfAkZ1//X CCRhYrLSW31gPt3r6YfF+wLLmESIjUd5IOfM96TR9s1wzK8YAXewiqv5TIMvzGxrqhsz DrPPTBQjv4nXaXy3jJeASMR0dutdBFMWnNghB8di69f+zF1iKqn30KktPgjViS6jFZ73 Ti0x1iRQGnFG4hAHBTRawtQgJs9ivecWIPGhikTNYDSIYTXxHvlBONFZQ/6DxV8vpDRY 0FHVOTTHOu5sklNVfQnxF7abXvIIxeqV6Ke3sAwQ6J/AhdDEgoVXkOtMs+TeEC0LAIW4 +1hg== X-Gm-Message-State: AHPjjUjJiFAbjdlFAgdZUx58EMdCmVa76bpvceJrrTQlXFlUx1gzFAVy 8YPkYcvrAfJhqbpVBaA= X-Google-Smtp-Source: ADKCNb5Erx8Q/rFGMWontVGCu8gzGC0N8AEeFGwiT0vyNg1HZNHb7AJ6lZugG3LwuK0v6NOsf7/Rtg== X-Received: by 10.107.166.2 with SMTP id p2mr1891336ioe.63.1504558390865; Mon, 04 Sep 2017 13:53:10 -0700 (PDT) Received: from bish (toroon0560w-lp130-01-174-88-79-183.dsl.bell.ca. [174.88.79.183]) by smtp.gmail.com with ESMTPSA id e17sm3887180iod.10.2017.09.04.13.53.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 04 Sep 2017 13:53:10 -0700 (PDT) Sender: Mark Johnston Date: Mon, 4 Sep 2017 16:53:08 -0400 From: Mark Johnston To: Kevin Bowling Cc: Johannes M Dieterich , freebsd-x11@freebsd.org, freebsd-current@freebsd.org Subject: Re: [RFC] future of drm1 in base Message-ID: <20170904205308.GB3048@bish> References: <20170903191908.GA1259@bish> <20170904193337.Horde.Wm3jEJaHwm_CuvGbAmSToz8@www.poelloepaeae.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.8.3 (2017-05-23) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Sep 2017 20:53:12 -0000 On Mon, Sep 04, 2017 at 01:28:38PM -0700, Kevin Bowling wrote: > I wasn't subscribed to -x11 earlier but do want to add some commentary > to this thread. > > The language describing these drivers in upstream is not at all > ambiguous WRT to how bad these are and Linux distributions have > dropped them: > > > menuconfig DRM_LEGACY > bool "Enable legacy drivers (DANGEROUS)" > depends on DRM && MMU > select DRM_VM > help > Enable legacy DRI1 drivers. Those drivers expose unsafe and dangerous > APIs to user-space, which can be used to circumvent access > restrictions and other security measures. For backwards compatibility > those drivers are still available, but their use is highly > inadvisable and might harm your system. > > You are recommended to use the safe modeset-only drivers instead, and > perform 3D emulation in user-space. > > Unless you have strong reasons to go rogue, say "N". > > > There seems to be some kind of misunderstanding that removing these > drivers is taking something away from users. I disagree. It does > _not_ deorbit HW support. We'd be giving users a supportable and > secure experience by dropping them. For 2d desktop it is likely that > a framebuffer is fast(er) as David states. On any reasonable CPU 3d > (like the server models people pointed out) may even be faster using > llvmpipe. I don't disagree in principle with removing the drivers, but if it's done it should be done for a good reason. I addressed the issue of the KLD name collision below, but security concerns are a more valid motivation for removing them. OTOH, the legacy drivers are not included in GENERIC kernels, so we're effectively doing the same thing as upstream Linux by making them opt-in by default, albeit without the scary warning. > > Regards, > > On Mon, Sep 4, 2017 at 12:33 PM, Johannes M Dieterich wrote: > > > > > > > > Mark Johnston – Sun., 3. September 2017 15:19 > >> On Sat, Sep 02, 2017 at 10:02:57PM -0400, Johannes M Dieterich wrote: > >> > Dear current/x11, > >> > > >> > please CC me on responses. > >> > > >> > I am writing you on behalf of the FreeBSDDesktop team concerning the > >> > future of drm1 in base. > >> > > >> > drm1 in base supports the following GPUs: > >> > * 3dfx Banshee/Voodoo3+ (tdfx) > >> > * ATI Rage 128 (r128) > >> > * ATI Rage Pro (mach64) > >> > * Matrox G200/G400 (mga) > >> > * Savage3D/MX/IX, Savage4, SuperSavage, Twister, ProSavage[DDR] (savage) > >> > * SIS 300/630/540 and XGI V3XE/V5/V8 (sis) > >> > * VIA Unichrome / Pro (via) > >> > > >> > Since their original introduction up to 2010 these drivers have mostly > >> > been maintained as part of larger cleanups. The newest hardware drm1 > >> > supports dates from 2004, if I am not mistaken, and most of the > >> > hardware is AGP-based. > >> > > >> > With the introduction of graphics/drm-next-kmod which brings its own > >> > drm.ko following the Linux notation, we are facing collisions between > >> > these old drivers' drm.ko and the newer one. > >> > >> I don't think this is a real problem. The reason one currently needs to > >> manually load the drm-next drm.ko (rather than just kldloading a driver > >> and having it pick up the right drm.ko automatically) is that our drm.ko > >> defines the same module ("drmn") as drm2.ko in the base system. So upon > >> attempting to load a drm-next driver, the kernel uses the linker hints > >> to load drm2.ko, which is incorrect. However, this can be addressed by > >> simply bumping the drmn version in the port and modifying the drivers > >> accordingly. I've submitted a 4-line PR which does exactly that. After > >> that change, we can modify the pkg-message to omit drm.ko from the > >> kld_list value. As a result, the name of our DRM module doesn't matter > >> since users don't need to specify it, so the collision with drm1 isn't a > >> problem. > >> > >> > We would like to hear if anybody still runs CURRENT on machines housing > >> > the above GPUs and relies on drm1. > >> > > >> > If there are still a significant number of people running CURRENT on > >> > this hardware in production, we would be willing to make a > >> > graphics/drm-legacy-kmod port. > >> > >> With the PR I mentioned above, I think it's a non-issue to keep drm1 in > >> the base system. Since there appear to be at least some users of those > >> drivers, I really think it would be preferable to avoid removing them > >> unless it's absolutely necessary. > > Your proposed solution does work, thanks for providing it! Let's move this conversation to a later point in time then. > > > > Johannes > > _______________________________________________ > > freebsd-x11@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-x11 > > To unsubscribe, send any mail to "freebsd-x11-unsubscribe@freebsd.org" From owner-freebsd-current@freebsd.org Tue Sep 5 17:21:33 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7019EE13E23; Tue, 5 Sep 2017 17:21:33 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 13A6A7707B; Tue, 5 Sep 2017 17:21:32 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 5DEB420B56; Tue, 5 Sep 2017 13:21:31 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute4.internal (MEProxy); Tue, 05 Sep 2017 13:21:31 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zyxst.net; h=cc :content-transfer-encoding:content-type:date:from:message-id :mime-version:subject:to:x-me-sender:x-me-sender:x-sasl-enc :x-sasl-enc; s=fm1; bh=lzfsDXYawMuQsaHRp5mslDG9MNW5qi4ujGsWdWf68 /w=; b=pU/DJcxG3DAvy5JeWbRVYgrrOjIRICOACGTIlYSrHINPxI2iE5iMbKtpy Nx1+HnGbTU5rZWMd2tDf3GtxB0YATu4ysCA5iCL/Ky4cBkvIfRDVq/wNmK1J3QX0 nS45xzhLK4eGQG3QduX4du8w3EQ2K5fRaXRcv4qYNXO5hCGEPfSetSMenJJ4UrGH SZuHjjwS9qxAVpIJmjiNzw64atIjCXlVn/3sGTdM8U0YcIHzQ9hu3ZwQnae8Bhh+ Sb/zxDEhJ8eJfg0gRyg2UXeKrGnXs3yXvPHozcMK4R8up/l2xAzkUTd81hkGvajC Bq8JBNDhpfa/ZWLwWt9Ru1LT2aE3w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=lzfsDXYawMuQsaHRp5 mslDG9MNW5qi4ujGsWdWf68/w=; b=JsDFNtBZAiUFK0P0H+SftuZ5FZlGLvc1N9 fj+vkKBEamEJH88881ZLLwLtfK3Eaz/7z+3kmGLm64zNKLENZ3yqxiTSorJpNal2 fzrWt1i+QH3R3aVddWse6HLjU0Y8/m7irq+ehzUQYpULjcdfc4vvXeNdWstx7JbA 2YkShtyGI9da5PzINH3uox4weFMgOyTs4Wl1IbOZAeVR8w1qrlVyqbRpOWQ45iF5 cRT561TZu6Yccnq8Pa1Q+tr5jb9yOVfTUhfl4qlMn3Nns4xOMyywyPzZmKxJx3J2 JphWa2ZgUffrveL9WiKh+l4bLe4ICVX4UbGZ04k005KDLkTWlmSw== X-ME-Sender: X-Sasl-enc: bf1x/kjbCanf+saYjY6lGjj2U/ZYd/RylKXFAqVPX+KA 1504632091 Received: from pumpkin.growveg.org (pumpkin.growveg.org [82.70.91.101]) by mail.messagingengine.com (Postfix) with ESMTPA id D8EE8240AF; Tue, 5 Sep 2017 13:21:30 -0400 (EDT) To: freebsd-virtualization@freebsd.org From: tech-lists Subject: openbsd 6.0 or 6.1 guest on freebsd-12 (current) host Openpgp: preference=signencrypt Cc: freebsd-current@freebsd.org Message-ID: Date: Tue, 5 Sep 2017 18:21:29 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Sep 2017 17:21:33 -0000 Hello freebsd-virtualization@ [also cc'd to freebsd-current], I'd like to run openbsd 6.0 or 6.1 guest under a 12-current bhyve system. I'd like it to run two cpus, so to use the openbsd smp kernel. I can see, from searching various mailing lists that there have been issues in getting openbsd to boot. Have these issues been fixed? Also, is there a howto for this? I found one here: http://www.allanjude.com/bsd/virtualization-host-bhyve.html but there's no date on the document, it's not on the official freebsd sites and so have no idea if the information is still current. I realise that HardenedBSD has fixed some issues with this, but I can't easily change the host to that OS unfortunately. thanks, -- J. From owner-freebsd-current@freebsd.org Wed Sep 6 10:23:17 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E1EFAE1F51B for ; Wed, 6 Sep 2017 10:23:17 +0000 (UTC) (envelope-from rainer@ultra-secure.de) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 4560373FEB for ; Wed, 6 Sep 2017 10:23:17 +0000 (UTC) (envelope-from rainer@ultra-secure.de) Received: by mailman.ysv.freebsd.org (Postfix) id 42E10E1F518; Wed, 6 Sep 2017 10:23:17 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 42700E1F517 for ; Wed, 6 Sep 2017 10:23:17 +0000 (UTC) (envelope-from rainer@ultra-secure.de) Received: from connect.ultra-secure.de (connect.ultra-secure.de [88.198.71.201]) by mx1.freebsd.org (Postfix) with ESMTP id 86BD173FE3 for ; Wed, 6 Sep 2017 10:23:15 +0000 (UTC) (envelope-from rainer@ultra-secure.de) Received: (Haraka outbound); Wed, 06 Sep 2017 12:23:09 +0200 Authentication-Results: connect.ultra-secure.de; auth=pass (login); spf=none smtp.mailfrom=ultra-secure.de Received-SPF: None (connect.ultra-secure.de: domain of ultra-secure.de does not designate 127.0.0.10 as permitted sender) receiver=connect.ultra-secure.de; identity=mailfrom; client-ip=127.0.0.10; helo=connect.ultra-secure.de; envelope-from= Received: from connect.ultra-secure.de (webmail [127.0.0.10]) by connect.ultra-secure.de (Haraka/2.6.2-toaster) with ESMTPSA id 8C30CC99-FB87-4507-96AA-522319E8A0DE.1 envelope-from (authenticated bits=0) (version=TLSv1/SSLv3 cipher=AES256-SHA verify=NO); Wed, 06 Sep 2017 12:23:07 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 06 Sep 2017 12:23:05 +0200 From: rainer@ultra-secure.de To: current@freebsd.org Subject: HP Gen10 servers Message-ID: <34399d599b5150221f3aef672fcf1dfe@ultra-secure.de> X-Sender: rainer@ultra-secure.de User-Agent: Roundcube Webmail/1.2.0 X-Haraka-GeoIP: --, , NaNkm X-Haraka-GeoIP-Received: X-Haraka-p0f: os="undefined undefined" link_type="undefined" distance=undefined total_conn=undefined shared_ip=Y X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on spamassassin X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham autolearn_force=no version=3.4.1 X-Haraka-Karma: score: 6, good: 249, bad: 0, connections: 249, history: 249, pass:all_good, relaying X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Sep 2017 10:23:18 -0000 Hi, HP Gen10 servers will bring in a lot of new stuff. Most importantly is the new RAID controllers. 028f Smart Storage PQI 12G SAS/PCIe 3 103c 0600 Smart Array P408i-p SR Gen10 103c 0601 Smart Array P408e-p SR Gen10 103c 0602 Smart Array P408i-a SR Gen10 103c 0603 Smart Array P408i-c SR Gen10 103c 0650 Smart Array E208i-p SR Gen10 103c 0651 Smart Array E208e-p SR Gen10 103c 0652 Smart Array E208i-c SR Gen10 103c 0654 Smart Array E208i-a SR Gen10 103c 0655 Smart Array P408e-m SR Gen10 103c 0700 Smart Array P204i-c SR Gen10 103c 0701 Smart Array P204i-b SR Gen10 103c 1100 Smart Array P816i-a SR Gen10 103c 1101 Smart Array P416ie-m SR G10 I've checked and it seems there isn't even support in CURRENT for these controllers. At least, I didn't see it: https://svnweb.freebsd.org/base/head/sys/dev/ciss/ciss.c?revision=311351&view=markup Or is it in a different driver? We've yet to receive a test-model, which I assume is going to take a couple of weeks. Is anybody working on this? We can still order Gen9 for a while, I'm told. But I'd like to be able to use the Gen10 servers. Regards Rainer From owner-freebsd-current@freebsd.org Wed Sep 6 12:15:31 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 92FE3E006FF; Wed, 6 Sep 2017 12:15:31 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 13FB46C6D0; Wed, 6 Sep 2017 12:15:30 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 31F7A20DA0; Wed, 6 Sep 2017 08:15:29 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute4.internal (MEProxy); Wed, 06 Sep 2017 08:15:29 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zyxst.net; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=jl/lZGaozB3S+w+rJu AFTlcixMu2DLYb5xt+ivA/rok=; b=nhQp2Yveb0JxOCXLjWrksa7oORao7WeBUU +LXKme1OBiPTBMkKnbvwg3qH9RcvTIo/pZCMV1zixvaywTx3fyMmMxTcsAxYfepc sBlm9VTP/AiCMiRTuHnrFsZX7ogPUwhkVlvptilLasIPNmRJhPzSKvvcwiBKkjUd Fxd/l+RfsqTDiTDOEMAep5p+DgsoDw2JEYbbs+M6WmHE1SbSibekV8d6ZXO0qPre 95gH1DBVwsF12GgFHKaSl2OovpALU2p83hUJPqOhQfu5w9rEE364WXIJCwRgjYpF MVCkXuuERJm33PLpCEM6szr8c/EGsjhC3tipDohKE+VPY+zFZrBQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=jl/lZGaozB3S+w+rJuAFTlcixMu2DLYb5xt+ivA/rok=; b=c71OW8C7 bT846UUQXaAIaCpr98Zb0BRR+GTN5dxBv0/VLgMYmfTguWL3/8iS9H0Aq2LSRRKn taBKfJ4N3K2vX3PuqQaRexNQTIK6hMCBAqyH1jdpRx6JT+r8gkZnhuVLzKJb88KO yCFejcje5uIFgvYj98NFvjAZAoumw+2W0/4U+/1lXHkRm1wkpHo/rJJORepoprYi SaLEWHQjaAKKrhdcfCuZtk/ESrwFalOgpmET7miNX1YyTqGGLnFHUSdBlbet1iz3 dwIzxA4N7ys3hwl8veU3DSScXiPgOvhaEq+fNbADe/cla9PdkERlHKr1xs9kmhfC 5Aj2GC40yjmrjQ== X-ME-Sender: X-Sasl-enc: 5z5fbmywdMLaGZJqDccZx8fLjDU5e3Q79htf3uueLuum 1504700128 Received: from pumpkin.growveg.org (pumpkin.growveg.org [82.70.91.101]) by mail.messagingengine.com (Postfix) with ESMTPA id A2E9D7E68E; Wed, 6 Sep 2017 08:15:28 -0400 (EDT) Subject: Re: openbsd 6.0 or 6.1 guest on freebsd-12 (current) host References: To: freebsd-virtualization@freebsd.org Cc: freebsd-current@freebsd.org, Jason Tubnor From: tech-lists Openpgp: preference=signencrypt Message-ID: Date: Wed, 6 Sep 2017 13:15:27 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Sep 2017 12:15:31 -0000 On 05/09/2017 22:56, Jason Tubnor wrote: > I'm not sure of the exact issue you are referring to but I run a lot of > OpenBSD 6.1 hosts under bhyve with GENERIC.MP .  You > can use either the grub-bhyve style boot or UEFI, both work fine. > > I have found the chyves framework (it is in packages) good for standing > up and managing bhyve guests - with ZFS, especially for a team that are > new to the platform.  You have to hack the following > /usr/local/lib/chyves files: > > chyves-guest-start > chyves-properties > chyves-resources > > to get 6.1 to install and boot (I yet to push those patches upstream). > > So to answer your question directly, there is currently no known issue > in getting bhyve to run OpenBSD 6.1 on Intel or AMD platforms.  Enjoy! Hi Jason, thanks for answering. I'll have a go at this. Up until now I've run all my VMs longhand in a screen. Good to know openbsd works. Have you encountered anything on openbsd in a bhyve that you've found not to work? thanks, -- J. From owner-freebsd-current@freebsd.org Wed Sep 6 15:23:51 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 891D6E07C2F; Wed, 6 Sep 2017 15:23:51 +0000 (UTC) (envelope-from crest@rlwinm.de) Received: from mail.rlwinm.de (mail.rlwinm.de [IPv6:2a01:4f8:171:f902::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2E48C75768; Wed, 6 Sep 2017 15:23:51 +0000 (UTC) (envelope-from crest@rlwinm.de) Received: from crest.local (unknown [IPv6:2a00:c380:c0d5:1:10be:4354:8df3:b2d8]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.rlwinm.de (Postfix) with ESMTPSA id CBC82A54D; Wed, 6 Sep 2017 15:23:40 +0000 (UTC) Subject: Re: openbsd 6.0 or 6.1 guest on freebsd-12 (current) host To: tech-lists , freebsd-virtualization@freebsd.org Cc: freebsd-current@freebsd.org References: From: Jan Bramkamp Message-ID: <638126a7-2527-5329-c952-f173c9b011b2@rlwinm.de> Date: Wed, 6 Sep 2017 17:23:39 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Sep 2017 15:23:51 -0000 On 05.09.17 19:21, tech-lists wrote: > Hello freebsd-virtualization@ > > [also cc'd to freebsd-current], > > I'd like to run openbsd 6.0 or 6.1 guest under a 12-current bhyve > system. I'd like it to run two cpus, so to use the openbsd smp kernel. I > can see, from searching various mailing lists that there have been > issues in getting openbsd to boot. Have these issues been fixed? > > Also, is there a howto for this? I found one here: > http://www.allanjude.com/bsd/virtualization-host-bhyve.html but there's > no date on the document, it's not on the official freebsd sites and so > have no idea if the information is still current. > > I realise that HardenedBSD has fixed some issues with this, but I can't > easily change the host to that OS unfortunately. > > thanks, I'm running OpenBSD 6.1 (with two virtual CPU cores) as bhyve guest on FreeBSD 11.1. The only problem I encountered is that it requires an external grub bootloader because the OpenBSD EFI boot code is incompatible with the bhyve EFI boot ROM. From owner-freebsd-current@freebsd.org Wed Sep 6 15:45:25 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CC060E08C48; Wed, 6 Sep 2017 15:45:25 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E91B47E346; Wed, 6 Sep 2017 15:45:24 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 340B9211D3; Wed, 6 Sep 2017 11:45:23 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute4.internal (MEProxy); Wed, 06 Sep 2017 11:45:23 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zyxst.net; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=3a+jtSaykjATus5Wrp d7ETBRguxsieZGyFLW7DLSZAk=; b=RNHrijbDUwh0BBDuegunKMZg0h4SWP8gDf wB0XCgzgALHeMja0inJNnmItPF6Ix+3Z/2pnoClkMuKT7U16DZwbLWpwuPyb9FjY 6JSfIy2u4cIr++c3uoyGgrrEh6Vfacl3boRTRgrgATNWUjcZZVcfwfznIkp+PXvN cR+hmPFa43DR/KkVnknBCY91HjBOf717VkvmO6gszJmCquiPuR/jrmeUtasJSQNO Xyf1IJKW8+/p716NQD0M/xz/4MrIz9EaqEEkej0zqzvZ6OnWjoRwouc1394LRwDt t9s2IkEivsXh4gwuhAEDw93GjqzHc7/VIMe228TAeygncyupT9OA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=3a+jtSaykjATus5Wrpd7ETBRguxsieZGyFLW7DLSZAk=; b=fGqDwScw bvH8LWGZGAra5DoyMfiBA/thmH8tOg8VUZV28hL6qeFRoKKYL6pDpA/y4OuO8d6N +5dqZAMJ2sa4frY+nu7x5tvSbhPSy+bFHG/c1BYF2aUsU1RirydHMLWVhBVkt9ui hl1PszNNmwcKBAx/qkb1r9C6Qu/yqMFdZwLVe2f25Cu79r6iy4eSevziufRc5X0v nh7zfVLaz6JeL/n6soId6TYZUSVDRU/BU+NGhdDo6180H2XKkneyXRIn0D8GHjHB MlD1p1UtTCKepzImK+posSvy+TUxgnePLZKrn/O644HcD3GLuoAuWWlEBMRCAUGu mf1cUr3E4pPx+Q== X-ME-Sender: X-Sasl-enc: o5IhOtFJxGbnIge1KGGAaEmy4SStF13RJ+onnqU1L2NJ 1504712722 Received: from pumpkin.growveg.org (pumpkin.growveg.org [82.70.91.101]) by mail.messagingengine.com (Postfix) with ESMTPA id A24347E464; Wed, 6 Sep 2017 11:45:22 -0400 (EDT) Subject: Re: openbsd 6.0 or 6.1 guest on freebsd-12 (current) host To: Jan Bramkamp , freebsd-virtualization@freebsd.org Cc: freebsd-current@freebsd.org References: <638126a7-2527-5329-c952-f173c9b011b2@rlwinm.de> From: tech-lists Openpgp: preference=signencrypt Message-ID: Date: Wed, 6 Sep 2017 16:45:20 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <638126a7-2527-5329-c952-f173c9b011b2@rlwinm.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Sep 2017 15:45:26 -0000 On 06/09/2017 16:23, Jan Bramkamp wrote: > I'm running OpenBSD 6.1 (with two virtual CPU cores) as bhyve guest on > FreeBSD 11.1. The only problem I encountered is that it requires an > external grub bootloader because the OpenBSD EFI boot code is > incompatible with the bhyve EFI boot ROM. Hi, Which external grub bootloader did you use? Was it sysutils/grub2-bhyve ? thanks, -- J. From owner-freebsd-current@freebsd.org Wed Sep 6 15:50:56 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AA383E0900D; Wed, 6 Sep 2017 15:50:56 +0000 (UTC) (envelope-from crest@rlwinm.de) Received: from mail.rlwinm.de (mail.rlwinm.de [IPv6:2a01:4f8:171:f902::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 22C6A7F512; Wed, 6 Sep 2017 15:50:56 +0000 (UTC) (envelope-from crest@rlwinm.de) Received: from crest.local (unknown [IPv6:2a00:c380:c0d5:1:10be:4354:8df3:b2d8]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.rlwinm.de (Postfix) with ESMTPSA id A2A9AA5E9; Wed, 6 Sep 2017 15:50:54 +0000 (UTC) Subject: Re: openbsd 6.0 or 6.1 guest on freebsd-12 (current) host To: tech-lists , freebsd-virtualization@freebsd.org Cc: freebsd-current@freebsd.org References: <638126a7-2527-5329-c952-f173c9b011b2@rlwinm.de> From: Jan Bramkamp Message-ID: Date: Wed, 6 Sep 2017 17:50:54 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Sep 2017 15:50:56 -0000 On 06.09.17 17:45, tech-lists wrote: > On 06/09/2017 16:23, Jan Bramkamp wrote: >> I'm running OpenBSD 6.1 (with two virtual CPU cores) as bhyve guest on >> FreeBSD 11.1. The only problem I encountered is that it requires an >> external grub bootloader because the OpenBSD EFI boot code is >> incompatible with the bhyve EFI boot ROM. > Hi, > > Which external grub bootloader did you use? Was it sysutils/grub2-bhyve ? I use the sysutils/grub2-bhyve port to load the OpenBSD kernel and runit for process supervision to keep the bhyve guest running unless the bhyve exit code signals an intend to perform shutdown. This allows the VMs to reboot themselves. From owner-freebsd-current@freebsd.org Wed Sep 6 21:53:56 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 415C1E19553; Wed, 6 Sep 2017 21:53:56 +0000 (UTC) (envelope-from jtubnor@gmail.com) Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::22c]) (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 6BC8A69E57; Wed, 6 Sep 2017 21:53:55 +0000 (UTC) (envelope-from jtubnor@gmail.com) Received: by mail-oi0-x22c.google.com with SMTP id x190so33556980oix.3; Wed, 06 Sep 2017 14:53:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=mUS4/YqziNNsvLwvflLOeVEXXglAxPZxhn1drN3vaoc=; b=R/PTvz01Ax9wcKmS+Wd4Mv949TbrtloZyNzOyHIyu9Eg8E3lEb8RW+xXCGADc1CTyf pCo0Ld5LzFCGPjcFthhJSLAWgzExg3Mas1hvM7Cas2gbbZNPeDfvXfYKMNiQoXMtKWHx w+25056sywF7cHBgihIIiss6bHk12QCWbaflZKoPdJQhDPhYXJCS38nnfOR22xyT6UKg vKPss6cBzXru8BYykELEIKIlr0df4JhVRfNs+gfTSQuNU8DKUGSvu5pmlpxO7IBJR7B/ elAvO73YAyCVi5RyoV3Rr4TEZ7CAqIHjtaeXfclplis/VESQTfvvnOutfUvKV3iFNXYF /teA== 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=mUS4/YqziNNsvLwvflLOeVEXXglAxPZxhn1drN3vaoc=; b=OHj3PxRF1k+vaUKT5d/wEX7ouZoJtck/X9oCRA5ggRiCOTm+6ScStlofzpHi3TEAvk iPIMRkgRpSomUba6t1s55dxcvbsXeHaf1frKKtxnxdzpao43O3j8JM8K0HdGoQgCBSEo il0c2IEdLqF7k9NgHnNI5h2LLnRyVjqLytuNEapExtRh32gwnF4x5NmEE2e6Z1KN3acW Pxc/SYgb4PlZsScEjxieeqQhk2d6W89Sz9z+vR8yupGR3l7sf0fa6qqdTiNxdFSpqOak UW9uYKnZtGDM+92OLCYIsDyglHevSw3Bbcz9h3gMLbOf/OLZn2nm8JBxTRnH6R80EzKc Yucw== X-Gm-Message-State: AHPjjUijKA2rmRT5/R9DPd28D4MbuC0BdgOU6ZfqCd7lgsosQB5hePeU jTEbZe4jR+x4jlgUPnsy8CnnHgsjwHujx8U= X-Google-Smtp-Source: ADKCNb6wI5c63tvBIatqn32SqjrHTRrh3gsgq8HzLqjPf/lpbrxnYZMZI8L/6aNkCwvJzzWe/eEiRMhqPsUl0dQ8BX8= X-Received: by 10.202.213.5 with SMTP id m5mr771611oig.35.1504734834342; Wed, 06 Sep 2017 14:53:54 -0700 (PDT) MIME-Version: 1.0 Sender: jtubnor@gmail.com Received: by 10.157.42.114 with HTTP; Wed, 6 Sep 2017 14:53:33 -0700 (PDT) In-Reply-To: References: From: Jason Tubnor Date: Thu, 7 Sep 2017 07:53:33 +1000 X-Google-Sender-Auth: 9GeOAFquQLRldAWblzg3jTjmNb8 Message-ID: Subject: Re: openbsd 6.0 or 6.1 guest on freebsd-12 (current) host To: tech-lists Cc: "freebsd-virtualization@freebsd.org" , freebsd-current@freebsd.org X-Mailman-Approved-At: Wed, 06 Sep 2017 21:59:51 +0000 Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Sep 2017 21:53:56 -0000 On 6 September 2017 at 22:15, tech-lists wrote: > > > Have you encountered anything on openbsd in a bhyve that you've found > not to work? > > As Thomas mentioned, there is/was a bug with certain CPUs, but this was due to the strict checking of CPU features that OpenBSD introduced ( https://marc.info/?l=openbsd-misc&m=149136173520510&w=2). Peter explained the switch to get around that issue (-w). The only other thing is Jumbo frame support, but that is really down to limits in VirtIO and not really a show stopper and doesn't affect anything in production for us. Enjoy bhyve, it has been a drop in replacement for our individual ESXi instances and has been bulletproof, which is good as we have hypervisor hosts over 6 hour drives away! (Oh the uplift from 11.0 to 11.1 was done remotely without nuking the host). Cheers, Jason. From owner-freebsd-current@freebsd.org Wed Sep 6 23:54:14 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C3F9FE1E0B7 for ; Wed, 6 Sep 2017 23:54:14 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-90.reflexion.net [208.70.210.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1FA7763E6F for ; Wed, 6 Sep 2017 23:54:13 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 29084 invoked from network); 6 Sep 2017 23:54:11 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 6 Sep 2017 23:54:11 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.2) with SMTP; Wed, 06 Sep 2017 19:54:11 -0400 (EDT) Received: (qmail 9555 invoked from network); 6 Sep 2017 23:54:11 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 6 Sep 2017 23:54:11 -0000 Received: from [192.168.1.109] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id B1C6BEC9274; Wed, 6 Sep 2017 16:54:10 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: head/lib/clang/freebsd_cc_version.h , FREEBSD_CC_VERSION : When is it supposed to update? Message-Id: <77543DF5-251C-438E-92A2-06574A687F9F@dsl-only.net> Date: Wed, 6 Sep 2017 16:54:09 -0700 To: Dimitry Andric , FreeBSD Toolchain , FreeBSD Current X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Sep 2017 23:54:15 -0000 When is: head/lib/clang/freebsd_cc_version.h supposed to have: FREEBSD_CC_VERSION updated? Back on 2016-May-23 Bryan Drewery wrote on the lists: > A critical note to toolchain developers, or anyone who touches the = Clang=20 > or GCC source files. If you modify these files or add a new target=20 > architecture into Clang, please bump the revision in the appropriate = file:=20 (It has moved since then.) Does this still apply? The most recent FREEBSD_CC_VERSION update was the clang 4 -> clang 5 = transition: > Revision 321369 - (view) (download) (annotate) - [select for diffs]=20 > Modified Sat Jul 22 11:08:25 2017 UTC (6 weeks, 4 days ago) by dim=20 > File length: 53 byte(s)=20 > Diff to previous 314564 > Upgrade our copies of clang, llvm, lld, lldb, compiler-rt and libc++ = to > 5.0.0 (trunk r308421). Upstream has branched for the 5.0.0 release, > which should be in about a month. Please report bugs and regressions, > so we can get them into the release. >=20 > Please note that from 3.5.0 onwards, clang, llvm and lldb require = C++11 > support to build; see UPDATING for more information. >=20 > MFC after: 2 months There have been updates since then (for example): 321664 321719 321723 322320 322326 (lldb so might not count) 322360 (lldb so might not count) 322474 (lldb so might not count) 322740 322855 323112 323245 =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-current@freebsd.org Thu Sep 7 06:58:45 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 20D46E0BF7C; Thu, 7 Sep 2017 06:58:45 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [IPv6:2001:470:7a58:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AB3D280E35; Thu, 7 Sep 2017 06:58:44 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from [IPv6:2001:470:7a58::11b8:8ff2:8d47:fe2b] (unknown [IPv6:2001:470:7a58:0:11b8:8ff2:8d47:fe2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id AAA3D374FB; Thu, 7 Sep 2017 08:58:41 +0200 (CEST) From: Dimitry Andric Message-Id: <2CE282A4-AF8C-47EC-944D-EB9686204DCA@FreeBSD.org> Content-Type: multipart/signed; boundary="Apple-Mail=_A0283FE9-8C8B-4148-80A7-E91AEFE99FB0"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: head/lib/clang/freebsd_cc_version.h , FREEBSD_CC_VERSION : When is it supposed to update? Date: Thu, 7 Sep 2017 08:58:36 +0200 In-Reply-To: <77543DF5-251C-438E-92A2-06574A687F9F@dsl-only.net> Cc: FreeBSD Toolchain , FreeBSD Current To: Mark Millard References: <77543DF5-251C-438E-92A2-06574A687F9F@dsl-only.net> X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Sep 2017 06:58:45 -0000 --Apple-Mail=_A0283FE9-8C8B-4148-80A7-E91AEFE99FB0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 7 Sep 2017, at 01:54, Mark Millard wrote: >=20 > When is: >=20 > head/lib/clang/freebsd_cc_version.h >=20 > supposed to have: >=20 > FREEBSD_CC_VERSION >=20 > updated? Back on 2016-May-23 Bryan Drewery wrote on the lists: >=20 >> A critical note to toolchain developers, or anyone who touches the = Clang >> or GCC source files. If you modify these files or add a new target >> architecture into Clang, please bump the revision in the appropriate = file: >=20 >=20 > (It has moved since then.) Does this still apply? >=20 > The most recent FREEBSD_CC_VERSION update was the clang 4 -> clang 5 = transition: For clang, I update FREEBSD_CC_VERSION much more conservatively now, since bumping it requires everybody to do a full compiler bootstrap during buildworld. Basically only when: * A major update is imported, such as going from 4.0.0 to 5.0.0. Since that touches many files, it is better to ensure all parts of world are built with the new major version. * There is a bug in the system compiler, preventing some or all users from building (parts of) world. -Dimitry --Apple-Mail=_A0283FE9-8C8B-4148-80A7-E91AEFE99FB0 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.1 iF0EARECAB0WIQR6tGLSzjX8bUI5T82wXqMKLiCWowUCWbDuHAAKCRCwXqMKLiCW ow31AKDrFP3FLPOi3NcsVm2zCjVuZ751aQCcDPNbUwJDQxRckDHobzZFUWLkXJY= =6iQX -----END PGP SIGNATURE----- --Apple-Mail=_A0283FE9-8C8B-4148-80A7-E91AEFE99FB0-- From owner-freebsd-current@freebsd.org Thu Sep 7 14:28:50 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7E1DBE20608; Thu, 7 Sep 2017 14:28:50 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-lf0-x232.google.com (mail-lf0-x232.google.com [IPv6:2a00:1450:4010:c07::232]) (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 9DDF780169; Thu, 7 Sep 2017 14:28:49 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-lf0-x232.google.com with SMTP id q132so24910367lfe.5; Thu, 07 Sep 2017 07:28:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=JXfy2bTttoWSWELvgCdbmcumDSL5eBa+rRpCqFwU4lI=; b=E/b19D6wQ16iPa2OEDEpPzaDTJ8rHfNXwbcAeNK4yKsD9XHgUYhHl67uAvogEtSBHS OCR9pTw/HckA54kHhG5+PbsCkadFZiOuYV//wHO4NVaIUXFweh4zDV3nX4Njavo81/4M kH1PngQrYC9kyuvrrSxRmoZo6WGklUgcL8LnsMRZEUSTXs6gW+V1yKM2Sv1JqUNeOfh+ BR1qrgNZAR6Ku8Oa5SkDJCigkkejW501f6m0Kzbm75gp46blKScrrO/RYX/2OyRonieV E/Ct8lhXsyEPA0eLT1v8rTSZSxUeQFq1Az//+EaRot4WyuCgGFXzBPfdBCBtqUWyp5YE v9gw== 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=JXfy2bTttoWSWELvgCdbmcumDSL5eBa+rRpCqFwU4lI=; b=InFjO896DSZ/rxHGxr4124ktIh/oj0Zo4lVPaayH3Gw5tUq7R/4p/HFzR0SiAMy/qj RGeoz5yIsTvv1SAo5IPzQ1+6CesH2/4EgKu+Mj/OUwRgmaa+qy9JEFbOXILhj6whe14J DoDaZo2IM8YtvOrjCjznh6/9yfKr+QX0wss9dnJ8c6nPDBd6jzYRjNTcsvX30Ylas07S S4D+mUNQXxKpcjXzI6qhf2YgpClqmbfR0tzwzDghpfzoFEBO5+hMMtMuHvy3vSFGEfqS qbFX1a9ootd9i4lJnBOJL+I1O+umHERx482DkIsqrdKc/zoqd71dF/zdxkYx6Vqzuap7 a/5Q== X-Gm-Message-State: AHPjjUhj8HLS2Jxe2iqNtSfJMSGBMZMe11XwLZ7mmV2OIv4/H701tzCV sbKs7MdwgyoqT46tma68n9lroIJiBQ== X-Google-Smtp-Source: AOwi7QBFVZYBhxZKWs6zUQG210tkv2IHlBhloNlOBWRtE5OBYoZIQK6P7eWPys5oG37kE8zYmvsJlGwOh2ZlgyiD2K4= X-Received: by 10.25.23.95 with SMTP id n92mr957405lfi.95.1504794527501; Thu, 07 Sep 2017 07:28:47 -0700 (PDT) MIME-Version: 1.0 Sender: asomers@gmail.com Received: by 10.179.26.6 with HTTP; Thu, 7 Sep 2017 07:28:46 -0700 (PDT) In-Reply-To: References: From: Alan Somers Date: Thu, 7 Sep 2017 08:28:46 -0600 X-Google-Sender-Auth: wRVeuEN4v-HcCsPZNH93TsDbWjA Message-ID: Subject: Re: openbsd 6.0 or 6.1 guest on freebsd-12 (current) host To: Jason Tubnor Cc: tech-lists , "freebsd-virtualization@freebsd.org" , FreeBSD CURRENT Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Sep 2017 14:28:50 -0000 On Wed, Sep 6, 2017 at 3:53 PM, Jason Tubnor wrote: > On 6 September 2017 at 22:15, tech-lists wrote: > >> >> >> Have you encountered anything on openbsd in a bhyve that you've found >> not to work? >> >> > As Thomas mentioned, there is/was a bug with certain CPUs, but this was due > to the strict checking of CPU features that OpenBSD introduced ( > https://marc.info/?l=openbsd-misc&m=149136173520510&w=2). Peter explained > the switch to get around that issue (-w). > > The only other thing is Jumbo frame support, but that is really down to > limits in VirtIO and not really a show stopper and doesn't affect anything > in production for us. > > Enjoy bhyve, it has been a drop in replacement for our individual ESXi > instances and has been bulletproof, which is good as we have hypervisor > hosts over 6 hour drives away! (Oh the uplift from 11.0 to 11.1 was done > remotely without nuking the host). > > Cheers, > > Jason. Do you have a semiautomated way to move bhyve instances between different hosts? Without such a feature, we can't replace all of our ESXi machines. -Alan From owner-freebsd-current@freebsd.org Fri Sep 8 01:00:34 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B37FAE1C61C for ; Fri, 8 Sep 2017 01:00:34 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from mail.protected-networks.net (mail.protected-networks.net [IPv6:2001:470:8d59:1::8]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.protected-networks.net", Issuer "Protected Networks CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id EC8813BF1; Fri, 8 Sep 2017 01:00:33 +0000 (UTC) (envelope-from imb@protected-networks.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d= protected-networks.net; h=content-transfer-encoding :content-language:content-type:content-type:mime-version :user-agent:date:date:message-id:subject:subject:from:from; s= 201508; t=1504832418; bh=4sOF/7kTFNgnkSVuY8w8Gpmno6hJ06clF6hDHFT A3bg=; b=Q/ZBEXua6UBOIEBxW/xidLYfW8qTncxiOi3mTG2IW8wDgjvt5c77LBm U/KtRG6SnWX8GnMY2J/wHwiBBNZG3H1zr0Ys7DzEAcP7aEgTzupGTlkSTRgpHQih 2+6XKFl6nUpuUZN+aBQhPA4DbLd26nh8FzIop49V6soXOVY9vvx0= Received: from toshi.auburn.protected-networks.net (toshi.auburn.protected-networks.net [192.168.1.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: imb@mail.protected-networks.net) by mail.protected-networks.net (Postfix) with ESMTPSA id ABAD51648; Thu, 7 Sep 2017 21:00:18 -0400 (EDT) To: freebsd-current , cem@freebsd.org From: Michael Butler Subject: SVN r323289 breaks i386 kernel compilation Message-ID: <74e90bcf-a289-02cf-2fed-ce2b302eab33@protected-networks.net> Date: Thu, 7 Sep 2017 21:00:17 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Sep 2017 01:00:35 -0000 On i386, this revision breaks compilation as follows: Building /usr/obj/usr/src/sys/SARAH/mca.o --- mca.o --- /usr/src/sys/x86/x86/mca.c:985:54: error: format specifies type 'unsigned long' but the argument has type 'uint64_t' (aka 'unsigned long long') [-Werror,-Wformat] printf("%s: 0x%lx: !valid | !present\n", __func__, misc); ~~~ ^~~~ %llx /usr/src/sys/x86/x86/mca.c:991:43: error: format specifies type 'unsigned long' but the argument has type 'uint64_t' (aka 'unsigned long long') [-Werror,-Wformat] printf("%s: 0x%lx: locked\n", __func__, misc); ~~~ ^~~~ %llx /usr/src/sys/x86/x86/mca.c:1000:58: error: format specifies type 'unsigned long' but the argument has type 'uint64_t' (aka 'unsigned long long') [-Werror,-Wformat] printf("%s: 0x%lx: count already enabled\n", __func__, misc); ~~~ ^~~~ %llx 3 errors generated. *** [mca.o] Error code 1 From owner-freebsd-current@freebsd.org Thu Sep 7 23:55:46 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DDA38E189F4; Thu, 7 Sep 2017 23:55:46 +0000 (UTC) (envelope-from jtubnor@gmail.com) Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::231]) (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 46A7676784; Thu, 7 Sep 2017 23:55:46 +0000 (UTC) (envelope-from jtubnor@gmail.com) Received: by mail-oi0-x231.google.com with SMTP id z73so3513665oia.2; Thu, 07 Sep 2017 16:55:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=WEro7CWTJ7s4KA7SB2uo6o/FZGLSBFBW7YhCtmCL2uE=; b=YcK60NDGZaLfcWHTm3dH1ACWaBhAxEOHiQ5A9gduJQWyDImVxmiSTOVki5vQjZZpWQ KZLrEfMn3PGBP4zgWwkAfgsKuR59va67xkDNhSHgG0hpW2ctOb98bzD3gnJszr5f0Qg5 8w6XjNz3zeaGI7aS5ryc370TGjn2oL8SYSMFrz2DrCidQh+3tD9fhHDv7W8Zfzcu5n4g 9SV3q9kkviNcLNwvS0kTwIH/FHIwC4rd0UQ0nOKqCeRQOEfx5kWQYtK/BSdR3hG7hVTG HuKyEWDUy5JAOZsI7LsTb7K3ZuLU4yYEuJiD8nHSPeXln3xu/Bb/BXylG/npjzUiqZyo ksYA== 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=WEro7CWTJ7s4KA7SB2uo6o/FZGLSBFBW7YhCtmCL2uE=; b=K0C3DBtOGGneb53aVk99y7WYqLG31qBlKQ7zyh+WgXiUvThFaIf6jIoHnlRHJO3ggY eu1xx5JOlPvn5HZ0UOjqvixUbcTW/9bJt7D5sF6vNw3rWCDHKlnffmLPFvtKWr7SsmGf j8XdHakxm65COBum3AT6aGIoIlMOinYdUdpwFjPbwYEo04o/FZ+p5R58gxyxaebEh7EH +LSuvOpV9Qfjg852NFHU0B9KP4yuVuW846GqaBHYbFGkcZ9p44vSpLL1Ky3MLvOGMiUU jpzAGBPh2d7z2g3UpCkorA+nihdceo1pwLCE/N497mpvEJVVt43jjecGq/WDQ06fCWb9 +xkw== X-Gm-Message-State: AHPjjUjntG6Awl9KcE4RhCG6IyR7wmJKdU+EoLY3XT1UpqAw7WeS3gTM +6k1RGaeFIes5X5lEDSTfXM+i5jBD3B0 X-Google-Smtp-Source: ADKCNb5uQzRFfteIlIvorDZjUNZU/DUmPll3ZkE7gXxarVetMUbVxdFcWnNf17Vld5Zwv8UfpfrfoUya6LTvzu1HIa0= X-Received: by 10.202.208.92 with SMTP id h89mr1379542oig.90.1504828545247; Thu, 07 Sep 2017 16:55:45 -0700 (PDT) MIME-Version: 1.0 Sender: jtubnor@gmail.com Received: by 10.157.42.114 with HTTP; Thu, 7 Sep 2017 16:55:24 -0700 (PDT) In-Reply-To: References: From: Jason Tubnor Date: Fri, 8 Sep 2017 09:55:24 +1000 X-Google-Sender-Auth: ZfIgWrZt1QxaeA1bSC0y0y9RZXU Message-ID: Subject: Re: openbsd 6.0 or 6.1 guest on freebsd-12 (current) host To: Alan Somers Cc: tech-lists , "freebsd-virtualization@freebsd.org" , FreeBSD CURRENT X-Mailman-Approved-At: Fri, 08 Sep 2017 01:45:48 +0000 Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Sep 2017 23:55:47 -0000 On 8 September 2017 at 00:28, Alan Somers wrote: > > > Do you have a semiautomated way to move bhyve instances between > different hosts? Without such a feature, we can't replace all of our > ESXi machines. > We are not using bhyve for those workloads (yet). Our vsphere environment still has life left in it but we never want to bet on one horse (I've been in too many positions where vendor lock has occurred and its been painful and expensive). However, where there are single hosts instances out at remote branches, it is bhyve all the way where we use to use individual instances of ESXi. So for your use case, it isn't there yet, but, if you don't need live migration, using zfs and/or iSCSI you could tool something together for offline migration of guests between hosts. Allowing you to get closer to the operating system (unlike the abstraction that is vsphere/ESXi), gives you the ability to take the excellent tools that FreeBSD has to offer and make them fit your application. From owner-freebsd-current@freebsd.org Fri Sep 8 17:15:42 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D11F7E2342A for ; Fri, 8 Sep 2017 17:15:42 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id AFA26393E for ; Fri, 8 Sep 2017 17:15:42 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (220-253-154-30.dyn.iinet.net.au [220.253.154.30]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id v88HFb6F000325 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 8 Sep 2017 10:15:40 -0700 (PDT) (envelope-from julian@freebsd.org) To: freebsd-current , Rick Macklem From: Julian Elischer Subject: extending the maximum filename length Message-ID: <0154558d-b2ad-af97-3960-3e392678f709@freebsd.org> Date: Sat, 9 Sep 2017 01:15:31 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Sep 2017 17:15:42 -0000 Has anyone using freeBSD ever increased NAME_MAX (filename maximum length) and have any experience with it? We ($JOB) would recompile the entire system so intra-system compatibility would probably be ok, and we have our own filesystem which would support it. But I wonder if anyone has tried it and hit unexpected problems. reason:  Chinese and Japanese people who have gotten into the habit of having a filename of 256 CHINESE/JAPANESE characters in Microsoft and want to store their files on a FreeBSD based server witout having to rename everything. (3 bytes for each of those characters giving a limit of 83 characters). (though since each character is a word the names if I could read them must be amazing) NFS behaviour is one issue I don't know but would be interested in..  could we SERVE such files? Julian From owner-freebsd-current@freebsd.org Fri Sep 8 17:21:28 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 75BE1E238D7 for ; Fri, 8 Sep 2017 17:21:28 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from mx.catwhisker.org (mx.catwhisker.org [198.144.209.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 235D83C0E; Fri, 8 Sep 2017 17:21:27 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.15.2/8.15.2) with ESMTP id v88HLQCg085206; Fri, 8 Sep 2017 17:21:26 GMT (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.15.2/8.15.2/Submit) id v88HLPrA085205; Fri, 8 Sep 2017 10:21:25 -0700 (PDT) (envelope-from david) Date: Fri, 8 Sep 2017 10:21:25 -0700 From: David Wolfskill To: Julian Elischer Cc: freebsd-current , Rick Macklem Subject: Re: extending the maximum filename length Message-ID: <20170908172125.GB1152@albert.catwhisker.org> Mail-Followup-To: David Wolfskill , Julian Elischer , freebsd-current , Rick Macklem References: <0154558d-b2ad-af97-3960-3e392678f709@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="a1HG+NiNtj/qClJd" Content-Disposition: inline In-Reply-To: <0154558d-b2ad-af97-3960-3e392678f709@freebsd.org> User-Agent: Mutt/1.8.3 (2017-05-23) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Sep 2017 17:21:28 -0000 --a1HG+NiNtj/qClJd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Sep 09, 2017 at 01:15:31AM +0800, Julian Elischer wrote: > Has anyone using freeBSD ever increased NAME_MAX (filename maximum=20 > length) and have any experience with it? >=20 > We ($JOB) would recompile the entire system so intra-system=20 > compatibility would probably be ok, and we have our own filesystem=20 > which would support it. >=20 > But I wonder if anyone has tried it and hit unexpected problems. > .... Not *strictly* a "filename length" issue, but one thing I (think I) recall encountering a while back was an (88-character?) upper limit on the length of the full pathname of a mount point. So that could prove ... annoying (if I actually recall correctly, and the situation has not changed since). Peace, David H. Wolfskill david@catwhisker.org http://www.cbc.ca/news/opinion/donald-trump-playbook-1.4265374 See http://www.catwhisker.org/~david/publickey.gpg for my public key. --a1HG+NiNtj/qClJd Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAEBCgBmBQJZstGVXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRDQ0I3Q0VGOTE3QTgwMUY0MzA2NEQ3N0Ix NTM5Q0M0MEEwNDlFRTE3AAoJEBU5zECgSe4XVDsH/34YWgxiN5BjDjtNW6ASQOhX GJbk/1godfPKE6KkEC3szCZvJNqdECOzzQ5cyFoYcUWhcr3e64NInYNzMdmurcst guOjduc1wMDxjK1LsVLAjJQk5WujXuWlCXl6eOgovElG1rVND5yBsQH79UYdRq25 F7glRh38jIdeJ+6PHDqXFoIJKgRCxkbJvcJ/XXaDjo/rn5LL7axBcVPMOaqy4rF5 OeA1/LBctaNKsNX8NcPuSJQMaXKiZr6Yc3xonxXys62tUs//tuX/zXZgEvZE8sSY Yv1YLuQo+n5bH5S1v4A8yQDBP4Y/9OKvmlvoj2qaqkBQIPXXFBEyroiaN0o+YxI= =IHUL -----END PGP SIGNATURE----- --a1HG+NiNtj/qClJd-- From owner-freebsd-current@freebsd.org Fri Sep 8 17:28:30 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7EB22E23DEC for ; Fri, 8 Sep 2017 17:28:30 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: from mail-yw0-f171.google.com (mail-yw0-f171.google.com [209.85.161.171]) (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 45FD463367; Fri, 8 Sep 2017 17:28:29 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: by mail-yw0-f171.google.com with SMTP id s62so9356174ywg.0; Fri, 08 Sep 2017 10:28:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc; bh=2MkBtjLSZt1CERO8N7vuaXs8eFFh1IXnZnpDQJTTNaM=; b=HAOBgyckCGq9NT3Lz8PBPrJEbFKIIzQ4eqhOHMYm90Ja3T6hIqVPsA+rSe7+hK2LBs cZRlFug41udKDDhviGq2g9dE/IG8BUeinTvPPQMSecla8TeioDMPCdNHZUcKsTlM57HP J8uaLThVwgwXtnP5U1GXy7aicVyOM86t0HfjczvygSYVrgINho+Pl2KNu397Vn97PYsn GMKnYVYInZ9YUwmo2ndT+M452fVNCcEi4FEjF/ufM6DS6IghR6d1AzoK7FCBu/Gweg1d ZWxGrX/LZ/6aDgS/3wfH3MW1f7Mn5U5eVXIJpCVfEOS4HOfGFq+KZ35JSbpoKxVexfrU MJzQ== X-Gm-Message-State: AHPjjUgTpC4e/1y7okAz40aTCx7tW2HIn6glJSY0EUD+UOTzTjBrJXga bjMvmYWjM280BiwMpm0= X-Received: by 10.37.49.213 with SMTP id x204mr2985129ybx.40.1504891703397; Fri, 08 Sep 2017 10:28:23 -0700 (PDT) Received: from mail-io0-f180.google.com (mail-io0-f180.google.com. [209.85.223.180]) by smtp.gmail.com with ESMTPSA id g72sm857818ywe.26.2017.09.08.10.28.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 08 Sep 2017 10:28:23 -0700 (PDT) Received: by mail-io0-f180.google.com with SMTP id j141so7086827ioj.4; Fri, 08 Sep 2017 10:28:23 -0700 (PDT) X-Google-Smtp-Source: AOwi7QDmylPOb3whv/tuNKv4O5KPBnK9ifGcMIOY5h3XvOwOz8HvvJkn8EVmB1CGtTUDsObNq0FjJxFIqwcuJTIczl8= X-Received: by 10.107.29.149 with SMTP id d143mr2196817iod.201.1504891702611; Fri, 08 Sep 2017 10:28:22 -0700 (PDT) MIME-Version: 1.0 Reply-To: cem@freebsd.org Received: by 10.2.81.131 with HTTP; Fri, 8 Sep 2017 10:28:22 -0700 (PDT) In-Reply-To: <0154558d-b2ad-af97-3960-3e392678f709@freebsd.org> References: <0154558d-b2ad-af97-3960-3e392678f709@freebsd.org> From: Conrad Meyer Date: Fri, 8 Sep 2017 10:28:22 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: extending the maximum filename length To: Julian Elischer Cc: freebsd-current , Rick Macklem Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Sep 2017 17:28:30 -0000 On Fri, Sep 8, 2017 at 10:15 AM, Julian Elischer wrote: > Has anyone using freeBSD ever increased NAME_MAX (filename maximum length) > and have any experience with it? > > We ($JOB) would recompile the entire system so intra-system compatibility > would probably be ok, and we have our own filesystem which would support it. > > But I wonder if anyone has tried it and hit unexpected problems. > > > reason: Chinese and Japanese people who have gotten into the habit of > having a filename of 256 CHINESE/JAPANESE characters in Microsoft and want > to store their files on a FreeBSD based server witout having to rename > everything. (3 bytes for each of those characters giving a limit of 83 > characters). > > (though since each character is a word the names if I could read them must > be amazing) > > > NFS behaviour is one issue I don't know but would be interested in.. could > we SERVE such files? Hey Julian, We've done exactly this at Isilon. Basically we bumped NAME_MAX and related constants out by 4x (maximum length of a UTF-8 encoded Unicode character, in bytes). So NAME_MAX is 1023, PATH_MAX is 4096, and a bunch of follow-on equivalent/related constants are bumped similarly. To avoid breaking too many ABIs, we've retained a SHORT_NAME_MAX constant of 255 which several non-filesystem NAME_MAX users were converted to. Stuff like module name APIs, procstat, etc. Individual filesystems are free to implement and restrict maximum component lengths in VOP_LOOKUP. For us, we retained 255 bytes for basically all filesystems (see e.g. r316509, r313475) aside from IFS (the OneFS filesystem). For IFS we check that component names are 255 ("MAXNAMCHARS") unicode codepoints or fewer (not all names shorter than NAME_MAX bytes are valid). NFS commonly does not support >255 byte names, so we have a hack there to export longer names as some shorter name plus a hash (total length of 255 bytes or fewer) to uniquely identify the file. SMB exports longer names just fine. Anyway, we'd love to shift some of these patches upstream, if there is interest in supporting this kind of thing. Sure, there are a few snags here and there and some ABIs change. But overall it seems to work pretty well. Best, Conrad From owner-freebsd-current@freebsd.org Fri Sep 8 18:30:58 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C7FC9E0300A for ; Fri, 8 Sep 2017 18:30:58 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: from mail-yw0-f193.google.com (mail-yw0-f193.google.com [209.85.161.193]) (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 8E73E65753; Fri, 8 Sep 2017 18:30:58 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: by mail-yw0-f193.google.com with SMTP id v72so1315072ywa.1; Fri, 08 Sep 2017 11:30:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to; bh=54NOogJH6PFO3xQAHrM4fxMoBfQ4rZFaGQj0PgJJnyA=; b=YOUufzlDHprmR6ZLBXn2f9YNUtkxUaHhOmxR9aGMSqNZ5Qce2E1r3jbO4oEwgp+fSr EmTI6jrzmPXFnD9D+bIeGBBwarWlIn27Cqs/P3+rPsd51I48NqplWr4/LX+rv0Zhax/D M0PqDSZUDYyrQ/7kd9mrNVfSOxn+zHLfQC8Jb46OUMX8Atbp7k+250XbgunFWfYzCqn/ ieRJtKaH+bMgfz4VqHRF6a1J3oHI8XCY5S3Du1eiyoxEX/MGi8/vAEzquGgoKihyEwLW uHCJv4M4otk/s1HHztCmJZy98EdVpD1wHmChA1PpnhRqy5D89rnC1P0JPxfp9lEnVIab 9BZg== X-Gm-Message-State: AHPjjUgvP+x52PSgr3iqhQ4NjYcoLC5LrvewL0V5ct865XV7glJwXU+U 63hDqAKE8ZQ8y5BTrBc= X-Received: by 10.13.210.6 with SMTP id u6mr3079825ywd.271.1504891938321; Fri, 08 Sep 2017 10:32:18 -0700 (PDT) Received: from mail-io0-f174.google.com (mail-io0-f174.google.com. [209.85.223.174]) by smtp.gmail.com with ESMTPSA id p205sm834107ywc.44.2017.09.08.10.32.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 08 Sep 2017 10:32:18 -0700 (PDT) Received: by mail-io0-f174.google.com with SMTP id j141so7107270ioj.4; Fri, 08 Sep 2017 10:32:17 -0700 (PDT) X-Google-Smtp-Source: AOwi7QCJM29CYr8MuuvXp3NrYR9jM1n6kFbJAUzzuWE42Eo+MXgyF5rLqM+URY1T5rcO+9bBnpDGpLGr6sR5HbD9L/0= X-Received: by 10.107.114.8 with SMTP id n8mr4281898ioc.174.1504891937467; Fri, 08 Sep 2017 10:32:17 -0700 (PDT) MIME-Version: 1.0 Reply-To: cem@freebsd.org Received: by 10.2.81.131 with HTTP; Fri, 8 Sep 2017 10:32:17 -0700 (PDT) In-Reply-To: <20170908172125.GB1152@albert.catwhisker.org> References: <0154558d-b2ad-af97-3960-3e392678f709@freebsd.org> <20170908172125.GB1152@albert.catwhisker.org> From: Conrad Meyer Date: Fri, 8 Sep 2017 10:32:17 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: extending the maximum filename length To: David Wolfskill , Julian Elischer , freebsd-current , Rick Macklem Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Sep 2017 18:30:58 -0000 On Fri, Sep 8, 2017 at 10:21 AM, David Wolfskill wrote: > On Sat, Sep 09, 2017 at 01:15:31AM +0800, Julian Elischer wrote: >> Has anyone using freeBSD ever increased NAME_MAX (filename maximum >> length) and have any experience with it? >> >> We ($JOB) would recompile the entire system so intra-system >> compatibility would probably be ok, and we have our own filesystem >> which would support it. >> >> But I wonder if anyone has tried it and hit unexpected problems. >> .... > > Not *strictly* a "filename length" issue, but one thing I (think > I) recall encountering a while back was an (88-character?) upper > limit on the length of the full pathname of a mount point. > > So that could prove ... annoying (if I actually recall correctly, > and the situation has not changed since). Hi David, I think mountpoint name length is largely an orthogonal issue. Fortunately, the 88 character limit (MNAMELEN) was already addressed recently (bumped to 1024) with the ino64 project. Best, Conrad From owner-freebsd-current@freebsd.org Sat Sep 9 00:38:12 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DBBE9E14F11 for ; Sat, 9 Sep 2017 00:38:12 +0000 (UTC) (envelope-from jakub_lach@mailplus.pl) Received: from n6.nabble.com (n6.nabble.com [162.255.23.37]) by mx1.freebsd.org (Postfix) with ESMTP id CB8CA71557 for ; Sat, 9 Sep 2017 00:38:11 +0000 (UTC) (envelope-from jakub_lach@mailplus.pl) Received: from n6.nabble.com (localhost [127.0.0.1]) by n6.nabble.com (Postfix) with ESMTP id 3F515197E873 for ; Fri, 8 Sep 2017 17:38:11 -0700 (MST) Date: Fri, 8 Sep 2017 17:38:11 -0700 (MST) From: Jakub Lach To: freebsd-current@freebsd.org Message-ID: <1504917491215-0.post@n6.nabble.com> In-Reply-To: <22949.42044.875179.603888@jerusalem.litteratus.org> References: <22949.42044.875179.603888@jerusalem.litteratus.org> Subject: Re: questions re updating to -CURRENT MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Sep 2017 00:38:13 -0000 I use 11-STABLE with Intel. Some time ago, there was a switch to drm2 here. Iirc I had to add kld_list="i915kms.ko to rc.conf and ensure that drm2/drm2 and drm2/i915kms are built (which should be default). Are you sure you are not using drm2 already? I would check with kldstat. The message in UPDATING is about removing old code from the tree. In any case, RELEASE to STABLE to CURRENT could be a less bumpy ride. -- Sent from: http://freebsd.1045724.x6.nabble.com/freebsd-current-f3875308.html From owner-freebsd-current@freebsd.org Sat Sep 9 03:34:57 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1C1B1E21BB0 for ; Sat, 9 Sep 2017 03:34:57 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-10.reflexion.net [208.70.210.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D33EB7C629 for ; Sat, 9 Sep 2017 03:34:56 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 18729 invoked from network); 9 Sep 2017 03:34:55 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 9 Sep 2017 03:34:55 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.2) with SMTP; Fri, 08 Sep 2017 23:34:55 -0400 (EDT) Received: (qmail 14498 invoked from network); 9 Sep 2017 03:34:54 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 9 Sep 2017 03:34:54 -0000 Received: from [192.168.1.109] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id 3789BEC7888; Fri, 8 Sep 2017 20:34:54 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: head -r 323246 /usr/src/sys/arm64/arm64/pmap.c:. . . error: no previous prototype for function 'pmap_invalidate_page' (also pmap_invalidate_range and pmap_invalidate_all) Message-Id: Date: Fri, 8 Sep 2017 20:34:53 -0700 Cc: FreeBSD Toolchain To: freebsd-arm , FreeBSD Current X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Sep 2017 03:34:57 -0000 This was from an amd64 -> arm64.aarch64 cross build context and was an attempt to build a debug kernel. # uname -apKU FreeBSD FreeBSDx64OPC 12.0-CURRENT FreeBSD 12.0-CURRENT r323246M amd64 = amd64 1200043 1200043 # svnlite info /usr/src/ | grep "Re[plv]" Relative URL: ^/head Repository Root: svn://svn.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 323246 Last Changed Rev: 323246 --- pmap.o --- /usr/src/sys/arm64/arm64/pmap.c:903:1: error: no previous prototype for = function 'pmap_invalidate_page' [-Werror,-Wmissing-prototypes] pmap_invalidate_page(pmap_t pmap, vm_offset_t va) ^ /usr/src/sys/arm64/arm64/pmap.c:917:1: error: no previous prototype for = function 'pmap_invalidate_range' [-Werror,-Wmissing-prototypes] pmap_invalidate_range(pmap_t pmap, vm_offset_t sva, vm_offset_t eva) ^ /usr/src/sys/arm64/arm64/pmap.c:934:1: error: no previous prototype for = function 'pmap_invalidate_all' [-Werror,-Wmissing-prototypes] pmap_invalidate_all(pmap_t pmap) ^ . . . 3 errors generated. *** [pmap.o] Error code 1 make[2]: stopped in = /usr/obj/cortexA53dbg_clang/arm64.aarch64/usr/src/sys/GENERIC-DBG .ERROR_TARGET=3D'pmap.o' = .ERROR_META_FILE=3D'/usr/obj/cortexA53dbg_clang/arm64.aarch64/usr/src/sys/= GENERIC-DBG/pmap.o.meta' .MAKE.LEVEL=3D'2' MAKEFILE=3D'' .MAKE.MODE=3D'meta missing-filemon=3Dyes missing-meta=3Dyes silent=3Dyes = verbose curdirOk=3Dyes' _ERROR_CMD=3D'cc -mcpu=3Dcortex-a53 -target aarch64-unknown-freebsd12.0 = --sysroot=3D/usr/obj/cortexA53dbg_clang/arm64.aarch64/usr/src/tmp = -B/usr/obj/cortexA53dbg_clang/arm64.aarch64/usr/src/tmp/usr/bin -c -O = -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt = -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h = -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mgeneral-regs-only = -ffixed-x18 -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall = -Wredundant-decls -Wnested-externs -Wstrict-prototypes = -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef = -Wno-pointer-sign -D__printf__=3D__freebsd_kprintf__ = -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas = -Wno-error-tautological-compare -Wno-error-empty-body = -Wno-error-parentheses-equality -Wno-error-unused-function = -Wno-error-pointer-sign -Wno-error-shift-negative-value = -Wno-error-address-of-packed-member -std=3Diso9899:1999 -Werror = /usr/src/sys/arm64/arm64/pmap.c; ctfconvert -L VERSION -g pmap.o;' = .CURDIR=3D'/usr/obj/cortexA53dbg_clang/arm64.aarch64/usr/src/sys/GENERIC-D= BG' .MAKE=3D'make' = .OBJDIR=3D'/usr/obj/cortexA53dbg_clang/arm64.aarch64/usr/src/sys/GENERIC-D= BG' .TARGETS=3D'all' DESTDIR=3D'' LD_LIBRARY_PATH=3D'' MACHINE=3D'arm64' MACHINE_ARCH=3D'aarch64' MAKEOBJDIRPREFIX=3D'/usr/obj/cortexA53dbg_clang/arm64.aarch64' MAKESYSPATH=3D'/usr/src/share/mk' MAKE_VERSION=3D'20170720' = PATH=3D'/usr/obj/cortexA53dbg_clang/arm64.aarch64/usr/src/tmp/legacy/usr/s= bin:/usr/obj/cortexA53dbg_clang/arm64.aarch64/usr/src/tmp/legacy/usr/bin:/= usr/obj/cortexA53dbg_clang/arm64.aarch64/usr/src/tmp/legacy/bin:/usr/obj/c= ortexA53dbg_clang/arm64.aarch64/usr/src/tmp/usr/sbin:/usr/obj/cortexA53dbg= _clang/arm64.aarch64/usr/src/tmp/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin' SRCTOP=3D'/usr/src' OBJTOP=3D'/usr/src' .MAKE.MAKEFILES=3D'/usr/src/share/mk/sys.mk = /usr/src/share/mk/local.sys.env.mk /usr/src/share/mk/src.sys.env.mk = /root/src.configs/src.conf.cortexA53dbg-clang-bootstrap.amd64-host = /usr/src/share/mk/bsd.mkopt.mk /usr/src/share/mk/bsd.suffixes.mk = /root/src.configs/make.conf /usr/src/share/mk/local.sys.mk = /usr/src/share/mk/src.sys.mk /dev/null Makefile = /usr/src/sys/conf/kern.pre.mk /usr/src/share/mk/bsd.own.mk = /usr/src/share/mk/bsd.opts.mk /usr/src/share/mk/bsd.cpu.mk = /usr/src/share/mk/bsd.compiler.mk /usr/src/share/mk/bsd.linker.mk = /usr/src/sys/conf/kern.opts.mk /usr/src/sys/conf/kern.post.mk = /usr/src/sys/conf/kern.mk' .PATH=3D'. = /usr/obj/cortexA53dbg_clang/arm64.aarch64/usr/src/sys/GENERIC-DBG' 1 error # grep -r pmap_invalidate_page /usr/src/sys/arm64/ | more /usr/src/sys/arm64/arm64/pmap.c:pmap_invalidate_page(pmap_t pmap, = vm_offset_t va) /usr/src/sys/arm64/arm64/pmap.c: = pmap_invalidate_page(kernel_pmap, va); /usr/src/sys/arm64/arm64/pmap.c: pmap_invalidate_page(pmap, va); /usr/src/sys/arm64/arm64/pmap.c: = pmap_invalidate_page(kernel_pmap, kernel_vm_end); /usr/src/sys/arm64/arm64/pmap.c: = pmap_invalidate_page(pmap, va); /usr/src/sys/arm64/arm64/pmap.c: pmap_invalidate_page(pmap, va); /usr/src/sys/arm64/arm64/pmap.c: = pmap_invalidate_page(pmap, pv->pv_va); /usr/src/sys/arm64/arm64/pmap.c: = pmap_invalidate_page(pmap, sva); /usr/src/sys/arm64/arm64/pmap.c: = pmap_invalidate_page(pmap, va); /usr/src/sys/arm64/arm64/pmap.c: = pmap_invalidate_page(pmap, va); /usr/src/sys/arm64/arm64/pmap.c: pmap_invalidate_page(pmap, va); /usr/src/sys/arm64/arm64/pmap.c: = pmap_invalidate_page(pmap, va); /usr/src/sys/arm64/arm64/pmap.c: pmap_invalidate_page(pmap, va); /usr/src/sys/arm64/arm64/pmap.c: = pmap_invalidate_page(pmap, pv->pv_va); /usr/src/sys/arm64/arm64/pmap.c: = pmap_invalidate_page(pmap, pv->pv_va); I will note that WERROR=3D was not in use: # more ~/src.configs/src.conf.cortexA53dbg-clang-bootstrap.amd64-host=20 TO_TYPE=3Daarch64 TOOLS_TO_TYPE=3D${TO_TYPE} # KERNCONF=3DGENERIC-DBG TARGET=3Darm64 .if ${.MAKE.LEVEL} =3D=3D 0 TARGET_ARCH=3D${TO_TYPE} .export TARGET_ARCH .endif # WITH_CROSS_COMPILER=3D WITHOUT_SYSTEM_COMPILER=3D # WITH_LIBCPLUSPLUS=3D WITHOUT_BINUTILS_BOOTSTRAP=3D WITH_ELFTOOLCHAIN_BOOTSTRAP=3D WITH_CLANG_BOOTSTRAP=3D WITH_CLANG=3D WITH_CLANG_IS_CC=3D WITH_CLANG_FULL=3D WITH_CLANG_EXTRAS=3D WITH_LLD_BOOTSTRAP=3D WITH_LLD=3D WITH_LLD_IS_LD=3D WITH_LLDB=3D # WITH_BOOT=3D WITHOUT_LIB32=3D # WITHOUT_GCC_BOOTSTRAP=3D WITHOUT_GCC=3D WITHOUT_GCC_IS_CC=3D WITHOUT_GNUCXX=3D # NO_WERROR=3D #WERROR=3D #MALLOC_PRODUCTION=3D # WITH_REPRODUCIBLE_BUILD=3D WITH_DEBUG_FILES=3D # #CROSS_BINUTILS_PREFIX=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ XCFLAGS+=3D -mcpu=3Dcortex-a53 XCXXFLAGS+=3D -mcpu=3Dcortex-a53 # There is no XCPPFLAGS but XCPP gets XCFLAGS content. I will note that there are other architectures with the likes of: /usr/src/sys/i386/include/pmap.h:void pmap_invalidate_page(pmap_t, = vm_offset_t); /usr/src/sys/mips/mips/pmap.c:static void pmap_invalidate_page(pmap_t = pmap, vm_offset_t va); /usr/src/sys/amd64/include/pmap.h:void pmap_invalidate_page(pmap_t, = vm_offset_t); =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-current@freebsd.org Sat Sep 9 14:02:29 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E7672E18303 for ; Sat, 9 Sep 2017 14:02:29 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 505156A424 for ; Sat, 9 Sep 2017 14:02:28 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from thor.intern.walstatt.dynvpn.de ([92.229.166.35]) by mail.gmx.com (mrgmx002 [212.227.17.190]) with ESMTPSA (Nemesis) id 0LaXEN-1dAzml0nOR-00mOHv for ; Sat, 09 Sep 2017 16:02:20 +0200 Date: Sat, 9 Sep 2017 16:02:09 +0200 From: "O. Hartmann" To: FreeBSD CURRENT Subject: compiler error: lib/libsbuf.a(subr_sbuf.o): relocation R_X86_64_32 against `_DefaultRuneLocale' can not be used when making a shared object Message-ID: <20170909160209.68077dd3@thor.intern.walstatt.dynvpn.de> Organization: WALSTATT User-Agent: OutScare 3.1415926 X-Operating-System: ImNotAnOperatingSystem 3.141592527 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; boundary="Sig_/yejlAoN6zKKW0v=YbE57YEV"; protocol="application/pgp-signature" X-Provags-ID: V03:K0:Dhnm83+ms5Ykm3JCByA+EpcHfM48wxWqpTUxBYZSD/A82L3wsrf VLW/I820vCsiF+8cNp99egYOiDlUGNwchOq0lozkfIqUY4wckuLI/UofXnsmopUCypB9+9o Huab7E5s2DZTMm2ZUxohK+4oz/TIw/sW0RkEj1Z7mwWAJ428RwUrlk0GRQjsQ7MYHahVIMN x41z4zlTmq1+X9a8vHKhw== X-UI-Out-Filterresults: notjunk:1;V01:K0:YOERqtScNzI=:hdcjdCVDslR/K+P3xOp0iR Yc6Sy8rRc6EDlAdpAnsyWRWNSuSCWHEXWW6MXeraw9JePpuL0Fpi23B9a2tHGhj5mL+NYoz1U DaDooycrhTaL35ePUECBizmSrEH/g0vFltdyfQHy3iyVaifsdS8KptRTCvb97Q+UWruKAiqdc iKAtKI6D6jvDLzeBAbIOew9iEj0WsLCVGcjvbtFdS9xKpnGcppFg/McaJvudcmdHLoYxoO56g UbAfxAlivXOwns35hLJdy0eFPCutk0VeV5ab1TpWn1fZa/4smfcZ+9kO4G8n2rqQPaxtP53v7 C+SMYDiZEL7Qdjq2LNlkJ6nqnaE1nO0EOzhqjsmj+THrZA7ji07iApohpaDC0dnahH8U0Uuvh i0i+Kbz7TijKiSGkge6g3NwpZdlaWD3WAg8XzrJmDZmrB6cdiWMWHP52NhEfDdQn6oIB5NO3p zmyVn4Go6lPKDU/xv5PQ/357iqtUrbaVTqGDyWVlwDpJA5+LDz+XlTPBBdANhupjB/bZx1cqh Raqd6bX45zGYzFMkRFPrBxHKZmrWUhDIEJQ1DfcEtzUfVq4JRYXWec8yzZjKztFMQIa/iF62U fgKmogOvFitmIk45Cz0bWcRbcrOBrdJ9cNeyZLCTSnQEJRLDg4puD7IH5nu11XVJVJr2rPgRX 5Gpm0UBcvOg3VzZKVd366qR86psEaJKHdjyoMhLPY0DpbGb2yJHwGJlRf/J+CPVy5NuPjXfFf EXtXfWKSxeVQxtjtmKOwLqOdAOTchrxYTuphfInMebMHrjkpb74ccTXqm/loZpLLGXopOY2bg 0MvUP1XEeuuKYuN/OJ4vk8DPnJLww== X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Sep 2017 14:02:30 -0000 --Sig_/yejlAoN6zKKW0v=YbE57YEV Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable This bug has just been introduced in the transition r323342 -> r323365: [...] building shared library libncurses.so.8 --- lib/libgeom__L --- /usr/obj/usr/src/tmp/usr/bin/ld: /usr/obj/usr/src/tmp/usr/lib/libsbuf.a(sub= r_sbuf.o): relocation R_X86_64_32 against `_DefaultRuneLocale' can not be used when ma= king a shared object; recompile with -fPIC /usr/obj/usr/src/tmp/usr/lib/libsbuf.a: could = not read symbols: Bad value cc: error: linker command failed with exit code 1 (use -= v to see invocation) *** [libgeom.so.5] Error code 1 make[4]: stopped in /usr/src/lib/libgeom .ERROR_TARGET=3D'libgeom.so.5' .ERROR_META_FILE=3D'/usr/obj/usr/src/lib/libgeom/libgeom.so.5.meta' .MAKE.LEVEL=3D'4' MAKEFILE=3D'' .MAKE.MODE=3D'meta missing-filemon=3Dyes missing-meta=3Dyes silent=3Dyes ve= rbose' _ERROR_CMD=3D'@echo building shared library libgeom.so.5; @rm -f libgeom.so= .5 libgeom.so; @sh /usr/src/tools/install.sh -l s libgeom.so.5 libgeom.so; cc -target x86_64-unknown-freebsd12.0 --sysroot=3D/usr/obj/usr/src/tmp -B/usr/obj/usr/= src/tmp/usr/bin -fstack-protector-strong -shared -Wl,-x -Wl,--fatal-warnings -Wl,--warn-sha= red-textrel -o libgeom.so.5 -Wl,-soname,libgeom.so.5 `NM=3D'nm' NMFLAGS=3D'' lorder ge= om_getxml.pico geom_stats.pico geom_xml2tree.pico geom_ctl.pico geom_util.pico | tsort -q= ` -lbsdxml -lsbuf;' .CURDIR=3D'/usr/src/lib/libgeom' --=20 O. Hartmann Ich widerspreche der Nutzung oder =C3=9Cbermittlung meiner Daten f=C3=BCr Werbezwecke oder f=C3=BCr die Markt- oder Meinungsforschung (=C2=A7 28 Abs.= 4 BDSG). --Sig_/yejlAoN6zKKW0v=YbE57YEV Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCWbP0YQAKCRDS528fyFhY lMCeAf9Xa14TiWPjwWI5BU/OocCj+8Ao61gZpmCocokFs2foJgP+EPeSgtacmMeW 0tofUvg1gq54xGuv33vaJMYjl2sCAgCIy5dMkckqcP0qHaf2Ql3aOMFBbt/jAGfi V4R5Ygr8PW5PQKFVsjWefl8+dU2d/mDTYDFOgv97AyhI5nAIpsBh =4UMb -----END PGP SIGNATURE----- --Sig_/yejlAoN6zKKW0v=YbE57YEV-- From owner-freebsd-current@freebsd.org Sat Sep 9 16:09:51 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 304FDE1EE48 for ; Sat, 9 Sep 2017 16:09:51 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 1616B6E3E8; Sat, 9 Sep 2017 16:09:50 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (106-68-193-181.dyn.iinet.net.au [106.68.193.181]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id v89G9dZK006001 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sat, 9 Sep 2017 09:09:43 -0700 (PDT) (envelope-from julian@freebsd.org) Subject: Re: extending the maximum filename length To: cem@freebsd.org Cc: freebsd-current , Rick Macklem References: <0154558d-b2ad-af97-3960-3e392678f709@freebsd.org> From: Julian Elischer Message-ID: <8d04540b-6daf-aa13-5648-0ec2541cbae6@freebsd.org> Date: Sun, 10 Sep 2017 00:09:33 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Sep 2017 16:09:51 -0000 On 9/9/17 1:28 am, Conrad Meyer wrote: > On Fri, Sep 8, 2017 at 10:15 AM, Julian Elischer wrote: >> Has anyone using freeBSD ever increased NAME_MAX (filename maximum length) >> and have any experience with it? >> >> We ($JOB) would recompile the entire system so intra-system compatibility >> would probably be ok, and we have our own filesystem which would support it. >> >> But I wonder if anyone has tried it and hit unexpected problems. >> >> >> reason: Chinese and Japanese people who have gotten into the habit of >> having a filename of 256 CHINESE/JAPANESE characters in Microsoft and want >> to store their files on a FreeBSD based server witout having to rename >> everything. (3 bytes for each of those characters giving a limit of 83 >> characters). >> >> (though since each character is a word the names if I could read them must >> be amazing) >> >> >> NFS behaviour is one issue I don't know but would be interested in.. could >> we SERVE such files? > Hey Julian, > > We've done exactly this at Isilon. > > Basically we bumped NAME_MAX and related constants out by 4x (maximum > length of a UTF-8 encoded Unicode character, in bytes). So NAME_MAX > is 1023, PATH_MAX is 4096, and a bunch of follow-on equivalent/related > constants are bumped similarly. > > To avoid breaking too many ABIs, we've retained a SHORT_NAME_MAX > constant of 255 which several non-filesystem NAME_MAX users were > converted to. Stuff like module name APIs, procstat, etc. > > Individual filesystems are free to implement and restrict maximum > component lengths in VOP_LOOKUP. For us, we retained 255 bytes for > basically all filesystems (see e.g. r316509, r313475) aside from IFS > (the OneFS filesystem). For IFS we check that component names are 255 > ("MAXNAMCHARS") unicode codepoints or fewer (not all names shorter > than NAME_MAX bytes are valid). > > NFS commonly does not support >255 byte names, so we have a hack there > to export longer names as some shorter name plus a hash (total length > of 255 bytes or fewer) to uniquely identify the file. SMB exports > longer names just fine. > > Anyway, we'd love to shift some of these patches upstream, if there is > interest in supporting this kind of thing. > > Sure, there are a few snags here and there and some ABIs change. But > overall it seems to work pretty well. > > Best, > Conrad > maybe we could get it into -current. It'd be silly to have to have people re-inventing hte wheel all the time. How about you put those changes into the reviews.freebsd.org and we can get some general consensus on them. We'll have to do similar for the Asian customers and anyone who uses UTF-8. So it would be silly to have to develop it all again (but subtly different of course). The key issue is how many system calls and other APIs would be broken, and how many would be broken in a non backwards compatible way? We would need it in a stable/10 and 11 branch but if the patch is isolated enough we could carry it forward until we get to 12. One has to allow people to do whatever they are used to with Windows. And in this case the issue is serving files over samba to windows machines. Julian From owner-freebsd-current@freebsd.org Sat Sep 9 20:05:04 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C3CC3E06D01 for ; Sat, 9 Sep 2017 20:05:04 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-10.reflexion.net [208.70.210.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 78CEF7714B for ; Sat, 9 Sep 2017 20:05:03 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 1931 invoked from network); 9 Sep 2017 20:05:02 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 9 Sep 2017 20:05:02 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.2) with SMTP; Sat, 09 Sep 2017 16:05:02 -0400 (EDT) Received: (qmail 630 invoked from network); 9 Sep 2017 20:05:02 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 9 Sep 2017 20:05:02 -0000 Received: from [192.168.1.109] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id CBAE3EC86EF; Sat, 9 Sep 2017 13:05:01 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: if_igb.ko symbolic link generation is still messed up in that it hard wires the path at installkernel time, messing up copying to other places Message-Id: Date: Sat, 9 Sep 2017 13:05:01 -0700 To: FreeBSD Toolchain , FreeBSD Current X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Sep 2017 20:05:04 -0000 [The example here happens to be for amd64 -> aarch64 cross builds.] The following is from after copying/moving the kernel from where it was originally, such as (locally) installed on the build machine. Example of symbolic links from some recent activity under head -r323246 (producing -r323246 again): # ls -lTt /media/boot/kernel/if_igb.ko /mnt/boot/kerndb/if_igb.ko lrwxr-xr-x 1 root wheel 25 Sep 8 22:47:36 2017 = /mnt/boot/kerndb/if_igb.ko -> /mnt/boot/kernel/if_em.ko lrwxr-xr-x 1 root wheel 68 Sep 6 20:27:20 2017 = /media/boot/kernel/if_igb.ko -> = /usr/obj/DESTDIRs/clang-cortexA53-installkernel/boot/kernel/if_em.ko In both of these cases the /mnt and /usr/obj/DESTDIRs/ prefixes would not exist for booting the PINE64 that the USB SSD is for: so file not found if a usage attempt is made. Installing absolute path links messes up even the /boot/kernel.old/ handling unless that process carefully replaces the original link that was in /boot/kernel/ . In the /mnt/boot/kerndb/if_igb.ko -> /mnt/boot/kernel/if_em.ko example I made a copy of the installed /mnt/boot/kernel/ area while the drive was still mounted. In the /usr/obj/DESTDIRs/ case I had installed to the local file system before attaching the USB SSD it was to be copied to. A relative path would not have such problems with binding to the wrong file or to no file when copies are made or renames along the path are done. [This has come up before on the lists, multiple-times as I remember.] =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-current@freebsd.org Sat Sep 9 22:32:36 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5622AE0EAC3; Sat, 9 Sep 2017 22:32:36 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0123.outbound.protection.outlook.com [104.47.34.123]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EDCC2804DB; Sat, 9 Sep 2017 22:32:35 +0000 (UTC) (envelope-from sjg@juniper.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ixvOBB79moCbUvaqIc3uOM+TmYsZRWflbeBi+Nx9Xfc=; b=ICXFR0YxKFomRhNWvcxyydSik2qzh0AhEzbL/htLjEvU8DS43YynHQJreojbTrNODMiJAYEfxgDy1dFVhaW189s4WyOPXr5WAneOGz/6Rvej80MQBDPtY9YWYNeKhZuKCMtYB0or7ZRJU8NHKTKM3tFRZbNyHbY4KuOMEbIrZbs= Received: from BN3PR05CA0029.namprd05.prod.outlook.com (10.174.64.39) by BN3PR0501MB1217.namprd05.prod.outlook.com (10.160.113.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.56.4; Sat, 9 Sep 2017 22:32:34 +0000 Received: from DM3NAM05FT043.eop-nam05.prod.protection.outlook.com (2a01:111:f400:7e51::200) by BN3PR05CA0029.outlook.office365.com (2603:10b6:400::39) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.56.4 via Frontend Transport; Sat, 9 Sep 2017 22:32:34 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.12) smtp.mailfrom=juniper.net; dsl-only.net; dkim=none (message not signed) header.d=none;dsl-only.net; dmarc=fail action=none header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.12 as permitted sender) Received: from p-emfe01a-sac.jnpr.net (66.129.239.12) by DM3NAM05FT043.mail.protection.outlook.com (10.152.98.112) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P256) id 15.1.1385.11 via Frontend Transport; Sat, 9 Sep 2017 22:32:33 +0000 Received: from p-mailhub01.juniper.net (10.160.2.17) by p-emfe01a-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Sat, 9 Sep 2017 15:31:51 -0700 Received: from kaos.jnpr.net (kaos.jnpr.net [172.21.30.60]) by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id v89MVoIx014156; Sat, 9 Sep 2017 15:31:51 -0700 (envelope-from sjg@juniper.net) Received: from kaos.jnpr.net (localhost [127.0.0.1]) by kaos.jnpr.net (Postfix) with ESMTP id D8823385520; Sat, 9 Sep 2017 15:31:50 -0700 (PDT) To: Mark Millard CC: FreeBSD Toolchain , FreeBSD Current , Subject: Re: if_igb.ko symbolic link generation is still messed up in that it hard wires the path at installkernel time, messing up copying to other places In-Reply-To: References: Comments: In-reply-to: Mark Millard message dated "Sat, 09 Sep 2017 13:05:01 -0700." From: "Simon J. Gerraty" X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 25.1.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <75574.1504996310.1@kaos.jnpr.net> Content-Transfer-Encoding: quoted-printable Date: Sat, 9 Sep 2017 15:31:50 -0700 Message-ID: <75575.1504996310@kaos.jnpr.net> X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:66.129.239.12; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(2980300002)(199003)(24454002)(189002)(97736004)(6266002)(6246003)(189998001)(5660300001)(7126002)(23726003)(2950100002)(55016002)(97756001)(6916009)(305945005)(356003)(117636001)(229853002)(478600001)(4326008)(69596002)(46406003)(110136004)(9686003)(54906002)(86362001)(7696004)(107886003)(105596002)(53416004)(76506005)(77096006)(106466001)(2906002)(2810700001)(47776003)(50986999)(76176999)(50226002)(68736007)(97876018)(53936002)(81166006)(81156014)(8676002)(8936002)(8746002)(50466002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1217; H:p-emfe01a-sac.jnpr.net; FPR:; SPF:SoftFail; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; DM3NAM05FT043; 1:Y+gf4p4OcgoaQkz4rcmeA0hSSuBpfJ/5xuB2m6gCmaHeXNqVRvbfRT90vPceQ43l5oS4tCePg8OPl0xGmO60GcQWtSoERQPkimrntobZ74R0xSwC7TkUBaA8S9pO1r48 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 8958f594-efdc-4dc7-ed26-08d4f7d2aa1b X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BN3PR0501MB1217; X-Microsoft-Exchange-Diagnostics: 1; BN3PR0501MB1217; 3:OkK6C9BQyphwVTgBAED5xT/ACTTKzfAInf+Ztbxw69uIGW2NesvQgPaf2PXnHTQ0uPY3thYuelv04wIDRwCa2BW1ATBdayhvUGzSDRnOV9BxmdfAMRflMtMJaIXq8QYmzPQF0YilXnnNoiy2FnFBGCbgIIJT20QArlNn5HWtuhqjfDIpDFH2XJEcE36nsvLrcxh4kg1sI02aygKo5ehDQFHkzjZvxNWWRRmeNQrocOXctyQCYJFtVN55MdpmHRCNLvCdG19T/dzZlr9C4vWwFPMK2H2erwJ0x7sIFFws0AGifHpEf/Wu8ddcZYOdLdBmLpOCnFnr6IPOZMZQwnt9YliLy7Sd3hgZnpxvHjH8xFc=; 25:dKB9gAyvh16bfPCu7tTvFNMYkSlniml6hy0dV2VCUleUZH6rZugGHG5F0ST9zFA9aTW9lg4WAMytB9vprghy/yvemd5g9p0fMK+Aovd8Mw3m1QTZEuNq0FRcZ0GD+gdWxljf2+2Cd4TzXwy7Eb44mkJG1z+kYO0tn4xU1D/4jUSZdq6pvXQY/z5EGz5pDtEVpb70OI1DeHVp3MPknDsEBJLRESjVObWVg92LKNgkj48jHpbUKy9U4R9rAakNNeBqhs3I0+EUpkRWA5A4e0vuHztBFEH1KTQoWyk/RrthtG3NThBf/uR/ddPdwlPIZEt+cx3BQwoLXxVQXzb/+1J4hQ== X-MS-TrafficTypeDiagnostic: BN3PR0501MB1217: X-Microsoft-Exchange-Diagnostics: 1; BN3PR0501MB1217; 31:eCWvEMEEOj1nqTZus2d29kKIRzT2yL/L3DWVxay2NZk24LTJBKaBm1tpmMrphyf1YnhDkhmhawyjqQwGuimNFpLfJobK/jsu0D3XQ06hp8SzOWcEAoLvGMlyvbGy8o5NSyR3fskeTRgBcSQaS41U59UzyHOsFlTcACBni1zSp3boYQkM0smOFZmtTNGXwoa5Qho7gZuole8AN05SVkX7cNo7hmwRJgxcsBfwBpLwXL8=; 20:H7TCPpsX4CId2qhC412q4fRrJFiwiD/24EMAz5OHxjaprfU//TRkr8p32R6a9Y61qIyDGPf1Su7KRzrAgva38PwuA5JuRqt4BpjFkbTu+KkHgh1Pfs6pw1KZAI1H087JBJSnDrub5SmdZ+5lFJEf2/4b09x9pnAr1wAEj1Tt1zUtZDLIxZBVukfwZCdysqDmfUpzCQd431d1Bg/7nw1aFg6F1EzCUNYJqMnHIdt9uRXrvSRvixZrjkd+sS46zt3hv6gWLjW9kmR9x7q2/CPHQu9bCfJvcMEE+zjYicH67VA5/vjypFzsgpupPkSZCCffIyb1FWni74P/7aABwPLX0Bu7MIi1LTIEPrXfBuoXgiPWwPZ4hrzv0X05IE1A8E3lRiJ3IqVsv5iGRxxjtgROjr5OLEdbAIPLn3OcT7XWJOACvgVUYiqd6R8YzdTJVt8L6mv9CyxnJa3HF00JnW91u+Wc2k/YV9bJmcudQGEUKM85ZSvFn0eCkhKiOhrexcQA X-Exchange-Antispam-Report-Test: UriScan:; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(93006095)(93003095)(10201501046)(100000703101)(100105400095)(3002001)(6055026)(6041248)(20161123555025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123560025)(20161123562025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN3PR0501MB1217; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN3PR0501MB1217; X-Microsoft-Exchange-Diagnostics: 1; BN3PR0501MB1217; 4:bwpscJEPSmnVVMXK/1HFeupHrYCB1pOLS5f9wHSIkCnKqdgGiJAIOflKmUucfFf6cSIqPVG6EGCttAwdjHNMbS8EGnoZKAW7IvI0uWdfoqIQf1WiT2HeFvHq85LAdtI+Dv32KI/rzclUExV6nIi54co6a7yQGDqQ1MR76LEfyVqDuHU0kxsYC1aSpNuzWW58FIKpWNAF9QZU0hx6S7suZrJk/ADAFtAGwDJl2zu4JyeK2QsjK22LCI6bgz3Dv7vr X-Forefront-PRVS: 0425A67DEF X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN3PR0501MB1217; 23:yNlFN/O0W91Vvlpe4a5P0JG/Cx1BoS2J3Knn+1y?= =?us-ascii?Q?0D/VhFUjtV7yubxTsLEe0doxVLhnhb9LEA65FiO/NWZCdXVldABK53EkibKf?= =?us-ascii?Q?a2D5qJjE6CJlaFVFPd/Eo6ZA3Ufgz6s0OJePRzglFoCG+XbfjdaWidYCw0CH?= =?us-ascii?Q?55JhDaBy8Efg4ajDi2pBArw3nEZIm6ArZulq1NuYV15fdY9uaWBq0/4NHqHS?= =?us-ascii?Q?ozrOtNRPvPaBRqihY31+W3cBGOr8YuiY630/WDk7P5ubk0qXRig/XedMYQRp?= =?us-ascii?Q?wKXeMZXpysDBZmtDyfGA1mvda4wDEUd/2pi2XcRs6ODYDUqoGQNJfDDqXv10?= =?us-ascii?Q?416ZgY+XZRXz/+bzwJI+wS/ZyP1Ibt04KjGhlSduBz+8usR+LBh+bksSBWdZ?= =?us-ascii?Q?jL43IigWRlg9EHSEJFAaol4iHcMbK5j+1+Xu0WqyG5Qrinq4Uubat7FVuY/w?= =?us-ascii?Q?keo6OlLFGZkl0GtbwmaPKMN73j0hW4I5mUqOa35sGo7koVzSBizDKiUKNjoV?= =?us-ascii?Q?+pFcUK17VGgZ7eOnvBgflW4qoe5j1vEMvqkiomZM8+9Ku2ExbW7QvbjAb6oY?= =?us-ascii?Q?095ehGmAmSs4omdo+4fTzjEtSETmbUd2tdyHF9BtLEmrQdXJi/xdxfMgK6Vz?= =?us-ascii?Q?uEcpNBh6H1yGpqAFEE7HWRxP0lgICyhR3/E5ITrQQYbLjFiMsqRTliaVbw+T?= =?us-ascii?Q?bA7T1YsLDL2z+h3BlhX9hGBjdhrPqmZtpjdiNfFPMknMtCavtolc6J7MAWGi?= =?us-ascii?Q?KU8jEOttJ5894mE3amatKRugh+DWL/15Ob8r+hFyIUEFGS4ZVJhgYfuHPAqK?= =?us-ascii?Q?XdiSf7ndmG7nbRD1GY5HAONc4U4aZ6r1vF+wJiF9Ntt70BNeJe6xTyvO04Nc?= =?us-ascii?Q?5vW5tvCfpfgxrnCyYVpU0s2fdNaH/6NPD4afRSqb1wnG6cKIO5YUiQ+KfYjV?= =?us-ascii?Q?hH1G8Dkzn7+HU5pHhCj9gkVoZ0KC37Wq6XxB8C+8j0VpbUr4O5YKtn7dQCH4?= =?us-ascii?Q?iHXJsJlimsPm1+JpGsGBJijILEfE9qRT6ArRKjq6fFAtIIwZDIMoYCXrzdqG?= =?us-ascii?Q?FFIx5C+70gFzSSmw6aijRCCfUaKWOYfh9P7cPBv9bwwogCyIHkGHtyqEG0lV?= =?us-ascii?Q?XgxxwAlhb+u9WQ0Gs6Nqt3E3iG05mzgbFr7ePi/1A43VeXrdcqmsQhtQmv1R?= =?us-ascii?Q?RhNuUX9KIfFOYnvh5M7na7IUixs4urGp8nR06SuDKVQMxtw3wZ5jfehqJaw?= =?us-ascii?Q?=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; BN3PR0501MB1217; 6:F0j90OhP8l1zmvHiemFqpEh9ZfwF6xZBRKu930Prg+/m9k1YwzWlelcP+69XHIaRfT0xw3Drf9aMQKZHiBk+glOTcnLWvuP923cvvw8wzczE+J6Ath658ZxAMwHJoGdZPg3PigtMSAHHdOyJhHTwu2z6/CY1Ho9QBMIb84lJgEBg5KPid9E8gTG2XE9vHfXqFvQOymlpzpH5V0zdC/rBukDodvL5+XVY2AM//X1GibFg1ou0HTvgCjQGamWVfIH+Q/385lJA7UITaYHZyKFpCe9mahwJOiqM3ipRsxAx83qWUasBdGtBjM2mpqB1S9gkbbbY/Qij6i3YTqOE5ojlDA==; 5:KFmNu3wRsliRiKMxW8rBP7HmcdCbFwZZJuXnZ2g+csOufCly+lTB7tDVS5KmAdX2YmCVYMHk/N7pdJCwyQRuHZSGd+trBwsL0iOFnyXXiSuVz7FC6eJUgIhsZ1jim2qcDOuwhihlgy4An+HyTMUX6g==; 24:N+Qz6kG4tT3b+e5+6y6mfqNUXShThl+sZKuh3NPkmaxJAGhYB5I7aTZLNs63LKLwm6/cKuEQK33Hhwqgbfhfui/sQD8fzvXv68tTCheoLUU=; 7:YMC35mytO0VkfG/AjZ6DyZ3F8/0VhnMtdT/97z+3oTR/rjKldB0HSeoRvVB/qewx6LeF1M7vQSPHsN4NUF+wj5O280HlIWw4VK90CPyOyP21R3nKw7++ebyTFsil3qheZ6p8KlelK/Okw6fv+CnQsE93UMYgImD/kQe3a2ISON5u/E2DY5GSO1ck6TIZqb8fl173r2legr99Iu2Wg8Ud+m8612e6XQPz0qvYRbLu714= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Sep 2017 22:32:33.1950 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.12]; Helo=[p-emfe01a-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1217 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Sep 2017 22:32:36 -0000 Mark Millard wrote: > # ls -lTt /media/boot/kernel/if_igb.ko /mnt/boot/kerndb/if_igb.ko > lrwxr-xr-x 1 root wheel 25 Sep 8 22:47:36 2017 /mnt/boot/kerndb/if_i= gb.ko -> /mnt/boot/kernel/if_em.ko > lrwxr-xr-x 1 root wheel 68 Sep 6 20:27:20 2017 /media/boot/kernel/if= _igb.ko -> /usr/obj/DESTDIRs/clang-cortexA53-installkernel/boot/kernel/if_= em.ko > = > In both of these cases the /mnt and /usr/obj/DESTDIRs/ prefixes > would not exist for booting the PINE64 that the USB SSD is for: > so file not found if a usage attempt is made. Yes, when making symlinks in presence of DESTDIR, the src should have $DESTDIR removed - the following should usually be safe: ln -s ${src#$DESTDIR} $DESTDIR${target#$DESTDIR} From owner-freebsd-current@freebsd.org Sat Sep 9 22:53:53 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 66460E0FD2D for ; Sat, 9 Sep 2017 22:53:53 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from pmta2.delivery6.ore.mailhop.org (pmta2.delivery6.ore.mailhop.org [54.200.129.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4883980EA2 for ; Sat, 9 Sep 2017 22:53:52 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: bb51ea2f-95b1-11e7-b50b-53dc5ecda239 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound2.ore.mailhop.org (Halon) with ESMTPSA id bb51ea2f-95b1-11e7-b50b-53dc5ecda239; Sat, 09 Sep 2017 22:53:44 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id v89MriRK004711; Sat, 9 Sep 2017 16:53:44 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1504997624.32063.69.camel@freebsd.org> Subject: Re: if_igb.ko symbolic link generation is still messed up in that it hard wires the path at installkernel time, messing up copying to other places From: Ian Lepore To: "Simon J. Gerraty" , Mark Millard Cc: FreeBSD Toolchain , FreeBSD Current Date: Sat, 09 Sep 2017 16:53:44 -0600 In-Reply-To: <75575.1504996310@kaos.jnpr.net> References: <75575.1504996310@kaos.jnpr.net> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Sep 2017 22:53:53 -0000 On Sat, 2017-09-09 at 15:31 -0700, Simon J. Gerraty wrote: > Mark Millard wrote: > > > > # ls -lTt /media/boot/kernel/if_igb.ko /mnt/boot/kerndb/if_igb.ko > > lrwxr-xr-x  1 root  wheel  25 Sep  8 22:47:36 2017 > > /mnt/boot/kerndb/if_igb.ko -> /mnt/boot/kernel/if_em.ko > > lrwxr-xr-x  1 root  wheel  68 Sep  6 20:27:20 2017 > > /media/boot/kernel/if_igb.ko -> /usr/obj/DESTDIRs/clang-cortexA53- > > installkernel/boot/kernel/if_em.ko > > > > In both of these cases the /mnt and /usr/obj/DESTDIRs/ prefixes > > would not exist for booting the PINE64 that the USB SSD is for: > > so file not found if a usage attempt is made. > Yes, when making symlinks in presence of DESTDIR, the src should have > $DESTDIR removed - the following should usually be safe: > > ln -s ${src#$DESTDIR} $DESTDIR${target#$DESTDIR} > I think the modern fix for this would be "install -l rs $src $DESTDIR", that should result in if_igb.ko -> if_em.ko without any dir nodes in the link. -- Ian From owner-freebsd-current@freebsd.org Sat Sep 9 23:35:15 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 83C5AE11B62 for ; Sat, 9 Sep 2017 23:35:15 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-10.reflexion.net [208.70.210.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 35D4181FEA for ; Sat, 9 Sep 2017 23:35:14 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 2435 invoked from network); 9 Sep 2017 23:35:13 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 9 Sep 2017 23:35:13 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.2) with SMTP; Sat, 09 Sep 2017 19:35:13 -0400 (EDT) Received: (qmail 23670 invoked from network); 9 Sep 2017 23:35:12 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 9 Sep 2017 23:35:12 -0000 Received: from [192.168.1.109] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id 3AA97EC94E5; Sat, 9 Sep 2017 16:35:12 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Missing in action during arm64/aarch64 builds: no pine64_plus.dtb to be found from buildkernel, installkernel, or u-boot-pine64 Message-Id: Date: Sat, 9 Sep 2017 16:35:11 -0700 To: FreeBSD Toolchain , freebsd-arm , FreeBSD Current X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Sep 2017 23:35:15 -0000 The context here is head -r323246 amd64 -> arm64/aarch64 cross build activity. =46rom installkernel : # find /usr/obj/DESTDIRs/clang-cortexA53-installkernel/ -name "*.dtb" = -print #=20 =46rom buildkernel : # find /usr/obj/cortexA53_clang/arm64.aarch64/ -name "*.dtb" -print #=20 =46rom installing u-boot-pine64 : # ls -lTd /usr/local/share/u-boot/u-boot-pine64/* -rw-r--r-- 1 root wheel 125 Sep 6 00:49:44 2017 = /usr/local/share/u-boot/u-boot-pine64/README -rw-r--r-- 1 root wheel 505940 Sep 6 00:49:43 2017 = /usr/local/share/u-boot/u-boot-pine64/u-boot-sunxi-with-spl.bin As stands the file must be manually produced. crochet goes to the trouble to have logic to build and install pine64_plus.dtb (based on arm64/pine64_plus.dts ). Is pine64_plus.dtb required for the likes of Pine64+ 2GB's? If yes: should it be automatically built and installed someplace for arm64/aarch64 builds (even if more manual steps are required to have the final placement on the Pine64 media)? =3D=3D=3D Mark Millard markmi at dsl-only.net