From owner-freebsd-hackers@freebsd.org Sun Dec 24 04:27:28 2017 Return-Path: Delivered-To: freebsd-hackers@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 A19F2E96433 for ; Sun, 24 Dec 2017 04:27:28 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-170.reflexion.net [208.70.210.170]) (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 6026467546 for ; Sun, 24 Dec 2017 04:27:27 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 30037 invoked from network); 24 Dec 2017 04:00:46 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 24 Dec 2017 04:00:46 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Sat, 23 Dec 2017 23:00:46 -0500 (EST) Received: (qmail 9107 invoked from network); 24 Dec 2017 04:00:45 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 24 Dec 2017 04:00:45 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 4FF1CEC7803; Sat, 23 Dec 2017 20:00:45 -0800 (PST) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: TARGET_ARCH=powerpc64 jump from head -r326192 to -r327075: g_event crashes with "instruction storage interrupt" [kldload -n filemon crashes the system] Date: Sat, 23 Dec 2017 20:00:44 -0800 References: <39C042C5-9800-464C-84AC-677DB45DA1C1@dsl-only.net> <244D5C85-E1E7-4349-A46A-1D275D54833F@dsl-only.net> To: FreeBSD PowerPC ML , FreeBSD Hackers In-Reply-To: <244D5C85-E1E7-4349-A46A-1D275D54833F@dsl-only.net> Message-Id: <55A9388E-2C04-4388-A4E9-F25574FAF129@dsl-only.net> X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Dec 2017 04:27:28 -0000 [I note some odd consequences when trying to build in geom_label to the kernel. filemon being built-in work fine for my use.] On 2017-Dec-22, at 10:33 PM, Mark Millard wrote: > [I attempted something that involved kldload -n filemon . > That gives a similar system crash (by the virtual address > reported and the type of exception). It seems similar to > geom_label_load="YES" in /boot/loader.conf getting a > crash.] > > On 2017-Dec-22, at 9:58 PM, Mark Millard wrote: > >> [Avoiding referencing partitions via labels >> avoided the crash.] >> >> On 2017-Dec-22, at 9:26 PM, Mark Millard wrote: >> >>> [Note: I experiment with using clang as the build and >>> system compiler for TARGET_ARCH=powerpc64 .] >>> >>> I attempted to update a old so-called PowerMac "Quad Core" >>> from head -r326192 to -r328075, noting special instructions >>> that have been published. (This was a non-debug kernel >>> build.) >>> >>> Unfortunately around the: >>> >>> . . . >>> cd0: 66.700MB/s transfers (UDMA4, ATPI 12bytes, PIO 65534bytes) >>> cd0: Attempt >>> Trying to mount from ufs:/dev/ufs/FBSDG5Lrootfs [rw,noatime]. . . >>> >>> There ends up being a repeatable kernel trap: >>> (transcribed from pictures, but with notes added) >>> >>> fatal kernel trap: >>> (NOTE: The above can be the line before the "Trying to mount" line, >>> after the "cd0: Attempt" line.) >>> >>> exception = 0x400 (instruction storage interrupt) >>> virtual address = 0x3c4c009438427518 >>> srr0 = 0x3c4c009438427518 >>> srr1 = 0x9000000040009032 >>> lr = 0x14234e8 >>> curthread = 0x3d52a80 >>> pid = 13, comm = g_event >>> >>> [ thread pid 13 tid 100019 ] >>> Stopped at 0x3c4c009438427518 >>> >>> It reports: >>> >>> Tracing command geom pid 13 tid 100019 td 0x3d52a80 (CPU 0) >>> 0xC0000000032966b0: at g_new_provider_event+0x144 >>> 0xC0000000032966f0: at g_run_events+0x530 >>> 0xC000000003296830: at g_event_procbody+0x94 >>> 0xC000000003296860: at fork_exit+0xd8 >>> 0xC0000000032968f0: at fork_trampoline+0x18 >>> 0xC000000003296920: at blocked_loop+0x38 >>> >>> These details do not vary between attempts. >>> >>> From what I gather the code jumped to 0x3c4c009438427518 >>> but that is not from an executable page for the context >>> at the time. >>> >>> On the -r326192 powerpc system /dev/ufs/FBSDG5Lrootfs >>> mounts just fine. >>> >> >> I adjusted: >> >> /boot/loader.conf >> /etc/rc.conf >> >> /etc/fstab >> >> to avoid use of: >> >> geom_label_load="YES" >> dumpdev="/dev/label/FBSDG5Lswap" >> >> /dev/ufs/FBSDG5Lrootfs / ufs rw,noatime 1 1 >> /dev/label/FBSDG5Lswap none swap sw 0 0 >> >> Using instead: >> >> dumpdev="/dev/ada0s4" >> >> /dev/ada0s3 / ufs rw,noatime 1 1 >> /dev/ada0s4 none swap sw 0 0 >> >> This allowed the boot to work normally. > > The use of filemon was tied to buildworld/buildkernel > related activity. > > But it was kldload that was listed in the crash from > the attempted kldload -n filemon. > > This would seem similar to having: > > geom_label_load="YES" > > in /boot/loader.conf I added: device filemon device geom_label to the kernel configuration files that I use. After booting, both work fine, including allowing explicit kldload -n NAME use (that avoids dynamically loading what is already present). But the boot time use of geom_label is not so lucky in that after booting there is no /dev/label/ or /dev/ufs/ or such. (No geom_label_load line.) Drives plugged into USB after booting do end up in those places. /dev/gpt/ as well. [The boot drive is apm --so, no gpt present to test at boot.] It seems that without /boot/loader.conf having: geom_label_load="YES" even with geom_label in the kernel it is not initialized early enough to be used with the initial devices, such as the boot drive. But it is also the case that with that line listed in /boot/loader.conf when the kernel has geom_label built-in, powerpc64 FreeBSD still crashes, sort of like geom_label_load does not involve the equivalent of -n in "kld -n geom_label". [From this I gather that if boot time label handling is desired, geom_label probably should not be built into the kernel because a second copy would need to be loaded anyway (when such loading is working).] === Mark Millard markmi at dsl-only.net From owner-freebsd-hackers@freebsd.org Sun Dec 24 05:42:30 2017 Return-Path: Delivered-To: freebsd-hackers@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 3972AE9BD91 for ; Sun, 24 Dec 2017 05:42:30 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-99.reflexion.net [208.70.210.99]) (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 EE6E469B1F for ; Sun, 24 Dec 2017 05:42:29 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 13367 invoked from network); 24 Dec 2017 05:42:23 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 24 Dec 2017 05:42:23 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Sun, 24 Dec 2017 00:42:23 -0500 (EST) Received: (qmail 15917 invoked from network); 24 Dec 2017 05:42:23 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 24 Dec 2017 05:42:23 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 8522DEC7803; Sat, 23 Dec 2017 21:42:22 -0800 (PST) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: TARGET_ARCH=powerpc64 jump from head -r326192 to -r327075: g_event crashes with "instruction storage interrupt" [kldload -n filemon crashes the system] Date: Sat, 23 Dec 2017 21:42:22 -0800 References: <39C042C5-9800-464C-84AC-677DB45DA1C1@dsl-only.net> <244D5C85-E1E7-4349-A46A-1D275D54833F@dsl-only.net> <55A9388E-2C04-4388-A4E9-F25574FAF129@dsl-only.net> To: FreeBSD PowerPC ML , FreeBSD Hackers In-Reply-To: <55A9388E-2C04-4388-A4E9-F25574FAF129@dsl-only.net> Message-Id: <68EA105F-3ADF-4CBB-BD59-7A9F18E52DB3@dsl-only.net> X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Dec 2017 05:42:30 -0000 [TARGET_ARCH=powerpc (gcc 4.2.1 based) does not have the problem. And my notes about geom_label being builtin were wrong about boot usage of labels when geom_label_load is not used /boot/loader.conf .] On 2017-Dec-23, at 8:00 PM, Mark Millard wrote: > [I note some odd consequences when trying to > build in geom_label to the kernel. filemon > being built-in work fine for my use.] > > On 2017-Dec-22, at 10:33 PM, Mark Millard wrote: > >> [I attempted something that involved kldload -n filemon . >> That gives a similar system crash (by the virtual address >> reported and the type of exception). It seems similar to >> geom_label_load="YES" in /boot/loader.conf getting a >> crash.] >> >> On 2017-Dec-22, at 9:58 PM, Mark Millard wrote: >> >>> [Avoiding referencing partitions via labels >>> avoided the crash.] >>> >>> On 2017-Dec-22, at 9:26 PM, Mark Millard wrote: >>> >>>> [Note: I experiment with using clang as the build and >>>> system compiler for TARGET_ARCH=powerpc64 .] >>>> >>>> I attempted to update a old so-called PowerMac "Quad Core" >>>> from head -r326192 to -r328075, noting special instructions >>>> that have been published. (This was a non-debug kernel >>>> build.) >>>> >>>> Unfortunately around the: >>>> >>>> . . . >>>> cd0: 66.700MB/s transfers (UDMA4, ATPI 12bytes, PIO 65534bytes) >>>> cd0: Attempt >>>> Trying to mount from ufs:/dev/ufs/FBSDG5Lrootfs [rw,noatime]. . . >>>> >>>> There ends up being a repeatable kernel trap: >>>> (transcribed from pictures, but with notes added) >>>> >>>> fatal kernel trap: >>>> (NOTE: The above can be the line before the "Trying to mount" line, >>>> after the "cd0: Attempt" line.) >>>> >>>> exception = 0x400 (instruction storage interrupt) >>>> virtual address = 0x3c4c009438427518 >>>> srr0 = 0x3c4c009438427518 >>>> srr1 = 0x9000000040009032 >>>> lr = 0x14234e8 >>>> curthread = 0x3d52a80 >>>> pid = 13, comm = g_event >>>> >>>> [ thread pid 13 tid 100019 ] >>>> Stopped at 0x3c4c009438427518 >>>> >>>> It reports: >>>> >>>> Tracing command geom pid 13 tid 100019 td 0x3d52a80 (CPU 0) >>>> 0xC0000000032966b0: at g_new_provider_event+0x144 >>>> 0xC0000000032966f0: at g_run_events+0x530 >>>> 0xC000000003296830: at g_event_procbody+0x94 >>>> 0xC000000003296860: at fork_exit+0xd8 >>>> 0xC0000000032968f0: at fork_trampoline+0x18 >>>> 0xC000000003296920: at blocked_loop+0x38 >>>> >>>> These details do not vary between attempts. >>>> >>>> From what I gather the code jumped to 0x3c4c009438427518 >>>> but that is not from an executable page for the context >>>> at the time. >>>> >>>> On the -r326192 powerpc system /dev/ufs/FBSDG5Lrootfs >>>> mounts just fine. >>>> >>> >>> I adjusted: >>> >>> /boot/loader.conf >>> /etc/rc.conf >>> >>> /etc/fstab >>> >>> to avoid use of: >>> >>> geom_label_load="YES" >>> dumpdev="/dev/label/FBSDG5Lswap" >>> >>> /dev/ufs/FBSDG5Lrootfs / ufs rw,noatime 1 1 >>> /dev/label/FBSDG5Lswap none swap sw 0 0 >>> >>> Using instead: >>> >>> dumpdev="/dev/ada0s4" >>> >>> /dev/ada0s3 / ufs rw,noatime 1 1 >>> /dev/ada0s4 none swap sw 0 0 >>> >>> This allowed the boot to work normally. >> >> The use of filemon was tied to buildworld/buildkernel >> related activity. >> >> But it was kldload that was listed in the crash from >> the attempted kldload -n filemon. >> >> This would seem similar to having: >> >> geom_label_load="YES" >> >> in /boot/loader.conf > > I added: > > device filemon > device geom_label > > to the kernel configuration files that > I use. > > After booting, both work fine, including > allowing explicit kldload -n NAME use > (that avoids dynamically loading what is > already present). > > But the boot time use of geom_label is > not so lucky in that after booting > there is no /dev/label/ or /dev/ufs/ > or such. (No geom_label_load line.) I had stupidly forgotten to change the /dev/. . . in the likes of /etc/fstab , /boot/loader.conf , and /etc/rc.conf to use /dev/label/. . . or /dev/ufs/. . . When used with the built-in geom_label (and no geom_label_load in /boot/loader.conf ), it works fine. > . . . (junk removed) . . . > > But it is also the case that with that > line listed in /boot/loader.conf when > the kernel has geom_label built-in, > powerpc64 FreeBSD still crashes, sort of > like geom_label_load does not involve > the equivalent of -n in > "kld -n geom_label". > > . . . (junk removed) . . . I updated from -r326192 to -r327075 for a TARGET_ARCH=powerpc context and it worked fine. But this is a gcc 4.2.1 based kernel build because with system clang 5 and the system binutils the kernel fails to build. (Unlike for devel/powerpc64-binutils , there is no devel/powerpc-binutils to use in cross builds.) === Mark Millard markmi at dsl-only.net From owner-freebsd-hackers@freebsd.org Sun Dec 24 06:55:28 2017 Return-Path: Delivered-To: freebsd-hackers@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 BC310EA0D01 for ; Sun, 24 Dec 2017 06:55:28 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-106.reflexion.net [208.70.210.106]) (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 7882B6BAED for ; Sun, 24 Dec 2017 06:55:27 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 32408 invoked from network); 24 Dec 2017 06:48:41 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 24 Dec 2017 06:48:41 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Sun, 24 Dec 2017 01:48:41 -0500 (EST) Received: (qmail 14215 invoked from network); 24 Dec 2017 06:48:41 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 24 Dec 2017 06:48:41 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id E5AAEEC88A2; Sat, 23 Dec 2017 22:48:40 -0800 (PST) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: TARGET_ARCH=powerpc64 jump from head -r326192 to -r327075: g_event crashes with "instruction storage interrupt" [clang-built kernel specific problem] Date: Sat, 23 Dec 2017 22:48:40 -0800 References: <39C042C5-9800-464C-84AC-677DB45DA1C1@dsl-only.net> <244D5C85-E1E7-4349-A46A-1D275D54833F@dsl-only.net> <55A9388E-2C04-4388-A4E9-F25574FAF129@dsl-only.net> <68EA105F-3ADF-4CBB-BD59-7A9F18E52DB3@dsl-only.net> To: Justin Hibbits , Nathan Whitehorn , FreeBSD PowerPC ML , FreeBSD Hackers In-Reply-To: <68EA105F-3ADF-4CBB-BD59-7A9F18E52DB3@dsl-only.net> Message-Id: <313C2310-ABEF-4BEE-A853-A9965680C3AC@dsl-only.net> X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Dec 2017 06:55:28 -0000 [Using devel/powerpc64-gcc to build the kernel produces a 64-bit kernel that does not crash for kldload use. clang 5.0.1 may be producing code that needs a "new" form of relocation compared to what kldload activity historically needed.] On 2017-Dec-23, at 9:42 PM, Mark Millard wrote: > [TARGET_ARCH=powerpc (gcc 4.2.1 based) does > not have the problem. And my notes about > geom_label being builtin were wrong about > boot usage of labels when geom_label_load > is not used /boot/loader.conf .] > > On 2017-Dec-23, at 8:00 PM, Mark Millard wrote: > >> [I note some odd consequences when trying to >> build in geom_label to the kernel. filemon >> being built-in work fine for my use.] >> >> On 2017-Dec-22, at 10:33 PM, Mark Millard wrote: >> >>> [I attempted something that involved kldload -n filemon . >>> That gives a similar system crash (by the virtual address >>> reported and the type of exception). It seems similar to >>> geom_label_load="YES" in /boot/loader.conf getting a >>> crash.] >>> >>> On 2017-Dec-22, at 9:58 PM, Mark Millard wrote: >>> >>>> [Avoiding referencing partitions via labels >>>> avoided the crash.] >>>> >>>> On 2017-Dec-22, at 9:26 PM, Mark Millard wrote: >>>> >>>>> [Note: I experiment with using clang as the build and >>>>> system compiler for TARGET_ARCH=powerpc64 .] >>>>> >>>>> I attempted to update a old so-called PowerMac "Quad Core" >>>>> from head -r326192 to -r328075, noting special instructions >>>>> that have been published. (This was a non-debug kernel >>>>> build.) >>>>> >>>>> Unfortunately around the: >>>>> >>>>> . . . >>>>> cd0: 66.700MB/s transfers (UDMA4, ATPI 12bytes, PIO 65534bytes) >>>>> cd0: Attempt >>>>> Trying to mount from ufs:/dev/ufs/FBSDG5Lrootfs [rw,noatime]. . . >>>>> >>>>> There ends up being a repeatable kernel trap: >>>>> (transcribed from pictures, but with notes added) >>>>> >>>>> fatal kernel trap: >>>>> (NOTE: The above can be the line before the "Trying to mount" line, >>>>> after the "cd0: Attempt" line.) >>>>> >>>>> exception = 0x400 (instruction storage interrupt) >>>>> virtual address = 0x3c4c009438427518 >>>>> srr0 = 0x3c4c009438427518 >>>>> srr1 = 0x9000000040009032 >>>>> lr = 0x14234e8 >>>>> curthread = 0x3d52a80 >>>>> pid = 13, comm = g_event >>>>> >>>>> [ thread pid 13 tid 100019 ] >>>>> Stopped at 0x3c4c009438427518 >>>>> >>>>> It reports: >>>>> >>>>> Tracing command geom pid 13 tid 100019 td 0x3d52a80 (CPU 0) >>>>> 0xC0000000032966b0: at g_new_provider_event+0x144 >>>>> 0xC0000000032966f0: at g_run_events+0x530 >>>>> 0xC000000003296830: at g_event_procbody+0x94 >>>>> 0xC000000003296860: at fork_exit+0xd8 >>>>> 0xC0000000032968f0: at fork_trampoline+0x18 >>>>> 0xC000000003296920: at blocked_loop+0x38 >>>>> >>>>> These details do not vary between attempts. >>>>> >>>>> From what I gather the code jumped to 0x3c4c009438427518 >>>>> but that is not from an executable page for the context >>>>> at the time. >>>>> >>>>> On the -r326192 powerpc system /dev/ufs/FBSDG5Lrootfs >>>>> mounts just fine. >>>>> >>>> >>>> I adjusted: >>>> >>>> /boot/loader.conf >>>> /etc/rc.conf >>>> >>>> /etc/fstab >>>> >>>> to avoid use of: >>>> >>>> geom_label_load="YES" >>>> dumpdev="/dev/label/FBSDG5Lswap" >>>> >>>> /dev/ufs/FBSDG5Lrootfs / ufs rw,noatime 1 1 >>>> /dev/label/FBSDG5Lswap none swap sw 0 0 >>>> >>>> Using instead: >>>> >>>> dumpdev="/dev/ada0s4" >>>> >>>> /dev/ada0s3 / ufs rw,noatime 1 1 >>>> /dev/ada0s4 none swap sw 0 0 >>>> >>>> This allowed the boot to work normally. >>> >>> The use of filemon was tied to buildworld/buildkernel >>> related activity. >>> >>> But it was kldload that was listed in the crash from >>> the attempted kldload -n filemon. >>> >>> This would seem similar to having: >>> >>> geom_label_load="YES" >>> >>> in /boot/loader.conf >> >> I added: >> >> device filemon >> device geom_label >> >> to the kernel configuration files that >> I use. >> >> After booting, both work fine, including >> allowing explicit kldload -n NAME use >> (that avoids dynamically loading what is >> already present). >> >> But the boot time use of geom_label is >> not so lucky in that after booting >> there is no /dev/label/ or /dev/ufs/ >> or such. (No geom_label_load line.) > > I had stupidly forgotten to change > the /dev/. . . in the likes of > /etc/fstab , /boot/loader.conf , > and /etc/rc.conf to use /dev/label/. . . > or /dev/ufs/. . . > > When used with the built-in geom_label > (and no geom_label_load in > /boot/loader.conf ), it works fine. > >> . . . (junk removed) . . . >> >> But it is also the case that with that >> line listed in /boot/loader.conf when >> the kernel has geom_label built-in, >> powerpc64 FreeBSD still crashes, sort of >> like geom_label_load does not involve >> the equivalent of -n in >> "kld -n geom_label". >> >> . . . (junk removed) . . . > > I updated from -r326192 to -r327075 for > a TARGET_ARCH=powerpc context and it > worked fine. > > But this is a gcc 4.2.1 based kernel build > because with system clang 5 and the system > binutils the kernel fails to build. (Unlike > for devel/powerpc64-binutils , there is no > devel/powerpc-binutils to use in cross > builds.) I built world and kernel based on devel/powerpc64-xtoolchain-gcc and installed the kernel it produced, leaving world as the previously installed clang-5.0.0-based build. kldload does not lead to crashes. Nor does /boot/loader.conf having: geom_label_load="YES" in it. So my guess is that clang is producing some form of relocation need that kldload support does not handle. I'l note that back at -r326192 this was not a problem for clang, so the clang 5.0.1 update may be what changed the status. === Mark Millard markmi at dsl-only.net From owner-freebsd-hackers@freebsd.org Sun Dec 24 20:01:28 2017 Return-Path: Delivered-To: freebsd-hackers@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 DD5C9EA7B1E for ; Sun, 24 Dec 2017 20:01:28 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-140.reflexion.net [208.70.210.140]) (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 8502367A9F for ; Sun, 24 Dec 2017 20:01:27 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 16103 invoked from network); 24 Dec 2017 19:34:41 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 24 Dec 2017 19:34:41 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Sun, 24 Dec 2017 14:34:41 -0500 (EST) Received: (qmail 10495 invoked from network); 24 Dec 2017 19:34:41 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 24 Dec 2017 19:34:41 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 77705EC7B31; Sun, 24 Dec 2017 11:34:40 -0800 (PST) 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: Re: TARGET_ARCH=powerpc64 jump from head -r326192 to -r327075: g_event crashes with "instruction storage interrupt" [R_PPC64_JMP_SLOT problem] Date: Sun, 24 Dec 2017 11:34:39 -0800 References: <39C042C5-9800-464C-84AC-677DB45DA1C1@dsl-only.net> <244D5C85-E1E7-4349-A46A-1D275D54833F@dsl-only.net> <55A9388E-2C04-4388-A4E9-F25574FAF129@dsl-only.net> <68EA105F-3ADF-4CBB-BD59-7A9F18E52DB3@dsl-only.net> <313C2310-ABEF-4BEE-A853-A9965680C3AC@dsl-only.net> To: Justin Hibbits , Nathan Whitehorn , FreeBSD PowerPC ML , FreeBSD Hackers In-Reply-To: <313C2310-ABEF-4BEE-A853-A9965680C3AC@dsl-only.net> Message-Id: X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Dec 2017 20:01:29 -0000 [History removed.] I have submitted bugzilla 224561 for the issue. The difference in the likes of filemon.ko produced by system clang 5.0.1 vs. devel/powerpc64-xtoolchain-gcc is. . . clang 5.0.1: Relocation section with addend (.rela.plt): r_offset r_info r_type st_value st_name + = r_addend 000000014480 000300000015 R_PPC64_JMP_SLOT 0000000000000000 copyinstr = + 0 000000014488 000400000015 R_PPC64_JMP_SLOT 0000000000000000 = devfs_set_cdevpriv + 0 . . . vs. devel/powerpc64-xtoolchain-gcc: Relocation section with addend (.rela.dyn): r_offset r_info r_type st_value st_name + = r_addend 0000000145c0 000000000016 R_PPC64_RELATIVE 0000000000000000 + 40d0 0000000145e0 000000000016 R_PPC64_RELATIVE 0000000000000000 + 145b0 . . . 000000014408 000600000026 R_PPC64_ADDR64 0000000000000000 sysent + = 0 000000014410 001100000026 R_PPC64_ADDR64 0000000000000000 = freebsd32_sysent + 0 Apparently R_PPC64_JMP_SLOT is mishandled and does not explicitly lead to rejection of the attempted dynamic load. It might be an issue if .rela.plt and R_PPC64_JMP_SLOT should even be generated instead of .rela.dyn and R_PPC64_RELATIVE and R_PPC64_ADDR64. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-hackers@freebsd.org Sun Dec 24 22:37:11 2017 Return-Path: Delivered-To: freebsd-hackers@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 DA2D1E85216 for ; Sun, 24 Dec 2017 22:37:11 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from shell1.rawbw.com (shell1.rawbw.com [198.144.192.42]) by mx1.freebsd.org (Postfix) with ESMTP id B11C86BDC1 for ; Sun, 24 Dec 2017 22:37:11 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from yv.noip.me (c-24-6-186-56.hsd1.ca.comcast.net [24.6.186.56]) (authenticated bits=0) by shell1.rawbw.com (8.15.1/8.15.1) with ESMTPSA id vBOMb5Zx011348 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Sun, 24 Dec 2017 14:37:05 -0800 (PST) (envelope-from yuri@rawbw.com) X-Authentication-Warning: shell1.rawbw.com: Host c-24-6-186-56.hsd1.ca.comcast.net [24.6.186.56] claimed to be yv.noip.me To: Freebsd hackers list From: Yuri Subject: Possible to prioritize IO requests based on the requesting process? Message-ID: Date: Sun, 24 Dec 2017 14:37:04 -0800 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Dec 2017 22:37:11 -0000 If I am watching a Netflix movie, I wouldn't want some batch file download to interrupt me, because, obviously, the response from an interactive process is expected with higher urgency, compared to a batch result. Assuming that disk/network IO is a bottleneck, is there a way to prioritize them based on pid? Yuri From owner-freebsd-hackers@freebsd.org Mon Dec 25 04:38:30 2017 Return-Path: Delivered-To: freebsd-hackers@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 5A6F2E9AA9E for ; Mon, 25 Dec 2017 04:38:30 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [78.47.246.247]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id E64BF75BF3 for ; Mon, 25 Dec 2017 04:38:29 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221] (may be forged)) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id vBP4cFmU046702 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 25 Dec 2017 05:38:16 +0100 (CET) (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: yuri@rawbw.com Received: from [10.58.0.4] ([10.58.0.4]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTPS id vBP4cBoa079394 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 25 Dec 2017 11:38:11 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: Possible to prioritize IO requests based on the requesting process? To: Yuri , Freebsd hackers list References: From: Eugene Grosbein Message-ID: <5A4080AF.70407@grosbein.net> Date: Mon, 25 Dec 2017 11:38:07 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=2.2 required=5.0 tests=BAYES_00, LOCAL_FROM, RDNS_NONE autolearn=no autolearn_force=no version=3.4.1 X-Spam-Report: * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 1.9 RDNS_NONE Delivered to internal network by a host with no rDNS * 2.6 LOCAL_FROM From my domains X-Spam-Level: ** X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on hz.grosbein.net X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Dec 2017 04:38:30 -0000 25.12.2017 5:37, Yuri пишет: > If I am watching a Netflix movie, I wouldn't want some batch file download to interrupt me, because, obviously, the response from an interactive process is expected with higher urgency, compared to a batch result. > > > Assuming that disk/network IO is a bottleneck, is there a way to prioritize them based on pid? Start by reading rctl(8) manual page. From owner-freebsd-hackers@freebsd.org Mon Dec 25 18:57:13 2017 Return-Path: Delivered-To: freebsd-hackers@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 05637E9FFF9 for ; Mon, 25 Dec 2017 18:57:13 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id D53076E9E9 for ; Mon, 25 Dec 2017 18:57:12 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mailman.ysv.freebsd.org (Postfix) id D1C9BE9FFF8; Mon, 25 Dec 2017 18:57:12 +0000 (UTC) Delivered-To: hackers@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 D16FCE9FFF7 for ; Mon, 25 Dec 2017 18:57:12 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::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 9A1F76E9E7 for ; Mon, 25 Dec 2017 18:57:12 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x232.google.com with SMTP id n14so7703973iob.4 for ; Mon, 25 Dec 2017 10:57:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:from:date:message-id:subject:to; bh=g8JHg8jtRRgD17BPEiVa1Wv37DriBN9kwCurp35GdIo=; b=vK2rfUgQNEo57oLSjnzHFU7vGK06+t6oLZ4aJzxBA0DCT3JbY//khkmla0oM2fTgsC grmxQ0PP56bJuIEdjp3Osf5/EdoO1nw7caDkoo9oQsIFaTYSW6PL8CYenwcsTrDfB0Y0 TJSj0oF5X5qTmXOKVSgc6FwrOPEWx6I7kvjsUNfmS/Dl0r85Lvi48EO1ffvxvF3uLMHl tEozDpci4WOLf288igR9ukXX7Gkp/EWIuz20U7ojXmu5218CEZjkXQvyk9l4EcmCp01K AEbEFbvd8wixP4UluY/gm9a2jKtBtH69rwGFoXDegcQHRo+SmrjcLnGVEJ8tQXPAJqeu I5og== 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:from:date:message-id:subject :to; bh=g8JHg8jtRRgD17BPEiVa1Wv37DriBN9kwCurp35GdIo=; b=ia97OpFBtL7n53W0/qvjPSx9T31JFHQJAypgSPfBDXPhxlPCWKm+xwkMhYIMEEywUn YO79bVgRDkprxuxlsEA4GHtG1poWnQvcJC4AvC+D9YSFn3SSvq0TkgBBsK2p90FhuJHx T0gOCHeY14aigt0URYeU3F8iiVVsCmfxssvOLHfitmuzv74/1URXPxo8TQd+eWdiDsMs b+tUxMsJePHQNe0i94FgmPGjjX93uDPjLSospJRdsCOOrAzfnKcaIvr+HeGiWpx/fUhZ obGID0cud+/7tkk/jotgR9hsOmZPXU5V8U3RokZmO7syu/ogG4AOadQ5OBfoMY1+jwJ4 QXHw== X-Gm-Message-State: AKGB3mKG+m8rsEmd7fiH9ZwcmSgrV7/DDy2ruUFVcHvKARlCTJ4/FlYb MSZRmztvacOd0+TRAc9axUZ26h7938iirL0SUBLm7rbk X-Google-Smtp-Source: ACJfBovXkzoaxp4xXUPxcwPGDbXsuhVvPdaqCroalwkqqo4nE79uBbgOr52hkIJPpOdSjlzeTv8A/GvNugCHfq4/73M= X-Received: by 10.107.149.5 with SMTP id x5mr25981596iod.136.1514228231567; Mon, 25 Dec 2017 10:57:11 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.108.204 with HTTP; Mon, 25 Dec 2017 10:57:10 -0800 (PST) X-Originating-IP: [2603:300b:6:5100:1052:acc7:f9de:2b6d] From: Warner Losh Date: Mon, 25 Dec 2017 11:57:10 -0700 X-Google-Sender-Auth: _zlStO7SAgTK9D9Ks4RgR9yizYc Message-ID: Subject: devmatch(8) committed .... To: "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Dec 2017 18:57:13 -0000 I've committed devmatch(8) to the tree in r327176. It's a building block for automating the loading of modules. While we can load modules today by adding FOO_load=YES to loader.conf, there's no easy way to load only the modules you need based on the hardware you have in the system. devmatch(8) provides the base framework to allow one to do that. It does this my looking at the PNP tables recorded in /boot/kernel/linker.hints. The version I've committed doesn't have the devd nor the rc.d integration. I've committed it for people to play with and give me feedback while those parts are finalized (and while other bugs are fixed). I don't intend to commit them until the kinks are worked out. Some notes: (1) You'll need a newly built kernel. Older kernels have minor bugs that allowed the terminating sentinel to be included in linker hints. All known oens, at least for amd64, have been fixed. (2) Lots and lots of drivers need to have their plug and play tables decorated. This is where I need people's help. I'll be writing up something for those that want to help. ISAPNP, PC Card and USB drivers already have this data. A few PCI drivers have it, and almost no ACPI drivers. The data is generally there, just not properly decorated for devmatch(8) and kldxref(8) to do their thing. (3) There's an issue with the USB pnp data. It's too long for the current devinfo(3) interfaces. I have fixes in the works to correct this. I could just bump the limits, but I want to do something more general and long term. (4) The end game for this is a GENERIC with most of the drivers removed that loads drivers automatically. Bootable storage drivers will have to remain for now until the loader can make use of this code.This is why the warning about hinted ISA devices went into the tree this week. (5) modules will print more than once. also the if_em/if_igb driver is a hard link so both of those will always print. Please send me your feedback. Happy Holidays! Warner From owner-freebsd-hackers@freebsd.org Mon Dec 25 21:45:03 2017 Return-Path: Delivered-To: freebsd-hackers@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 0BBE7EA820B for ; Mon, 25 Dec 2017 21:45:03 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id E1AB174DD0 for ; Mon, 25 Dec 2017 21:45:02 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: by mailman.ysv.freebsd.org (Postfix) id DD869EA820A; Mon, 25 Dec 2017 21:45:02 +0000 (UTC) Delivered-To: hackers@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 DB730EA8209 for ; Mon, 25 Dec 2017 21:45:02 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.blih.net", Issuer "mail.blih.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 52FC974DCF for ; Mon, 25 Dec 2017 21:45:01 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) by mail.blih.net (OpenSMTPD) with ESMTP id dfed1bbb; Mon, 25 Dec 2017 22:44:59 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=mail; bh=YUzH4BDEohLZGJ0SoIoQHQu8Z48=; b=UE11gHlrAMNP9Kiu82weawQbSF9u MPFUTbJio9OY1FIKaXTq97hAAJSNmuG/og+gEuvxU0sEZfKi7jH46dOURWPJbVeR 7jx6De/VDeWKO3pxZI0YSFGoz3QxfGH13tIs9E0h2l1KAWSTNYnpeI0MgCb2jGcR o7bWtGjuMwGc2RQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; q=dns; s= mail; b=K90d8bQJn5WC78bhp0wTqjBhq6VYjMcKZMxVwAB3co4xf5in3JoRlQuH au1v1C3n5dv8WurxWdVx8v1caNzIVV1PCuIrMLo++ZKGUg6xWETfHd801D0bNvj6 tRLFJA4J9Tjd63XMuSYRumll29c3vinWclNbGFuxSY1+5h9/YjI= Received: from arcadia (j1a01-1-78-205-69-41.fbx.proxad.net [78.205.69.41]) by mail.blih.net (OpenSMTPD) with ESMTPSA id 6498c3c5 TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Mon, 25 Dec 2017 22:44:59 +0100 (CET) Date: Mon, 25 Dec 2017 22:44:58 +0100 From: Emmanuel Vadot To: Warner Losh Cc: "freebsd-hackers@freebsd.org" Subject: Re: devmatch(8) committed .... Message-Id: <20171225224458.e925f49181221a2315a1974f@bidouilliste.com> In-Reply-To: References: X-Mailer: Sylpheed 3.6.0 (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-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Dec 2017 21:45:03 -0000 Hello Warner, On Mon, 25 Dec 2017 11:57:10 -0700 Warner Losh wrote: > I've committed devmatch(8) to the tree in r327176. It's a building block > for automating the loading of modules. While we can load modules today by > adding FOO_load=YES to loader.conf, there's no easy way to load only the > modules you need based on the hardware you have in the system. devmatch(8) > provides the base framework to allow one to do that. It does this my > looking at the PNP tables recorded in /boot/kernel/linker.hints. > > The version I've committed doesn't have the devd nor the rc.d integration. > I've committed it for people to play with and give me feedback while those > parts are finalized (and while other bugs are fixed). I don't intend to > commit them until the kinks are worked out. > > Some notes: > > (1) You'll need a newly built kernel. Older kernels have minor bugs that > allowed the terminating sentinel to be included in linker hints. All known > oens, at least for amd64, have been fixed. > (2) Lots and lots of drivers need to have their plug and play tables > decorated. This is where I need people's help. I'll be writing up something > for those that want to help. ISAPNP, PC Card and USB drivers already have > this data. A few PCI drivers have it, and almost no ACPI drivers. The data > is generally there, just not properly decorated for devmatch(8) and > kldxref(8) to do their thing. > (3) There's an issue with the USB pnp data. It's too long for the current > devinfo(3) interfaces. I have fixes in the works to correct this. I could > just bump the limits, but I want to do something more general and long term. > (4) The end game for this is a GENERIC with most of the drivers removed > that loads drivers automatically. Bootable storage drivers will have to > remain for now until the loader can make use of this code.This is why the > warning about hinted ISA devices went into the tree this week. > (5) modules will print more than once. also the if_em/if_igb driver is a > hard link so both of those will always print. > > Please send me your feedback. Happy Holidays! > > Warner This is all excellent news I can't wait to try. I've not currently started to look at the code but have you thought of fdt based system ? I would love a minimal GENERIC arm/arm64 kernel with everything else in modules. I know we still have to do a lot of work in the arm world to make almost everything usable in module form. -- Emmanuel Vadot From owner-freebsd-hackers@freebsd.org Mon Dec 25 23:16:07 2017 Return-Path: Delivered-To: freebsd-hackers@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 1402BE80DE1 for ; Mon, 25 Dec 2017 23:16:07 +0000 (UTC) (envelope-from wlosh@bsdimp.com) 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 E088F77981 for ; Mon, 25 Dec 2017 23:16:06 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mailman.ysv.freebsd.org (Postfix) id DFE4BE80DE0; Mon, 25 Dec 2017 23:16:06 +0000 (UTC) Delivered-To: hackers@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 DF87AE80DDF for ; Mon, 25 Dec 2017 23:16:06 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::22a]) (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 A36BC7797F for ; Mon, 25 Dec 2017 23:16:06 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x22a.google.com with SMTP id z6so21021634iti.4 for ; Mon, 25 Dec 2017 15:16:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=pok2ezpPoFHplItpn6yU0uLbkFeNjqWMvxLnAUgQqjk=; b=ywk9IZ5c1rGj0UbKAM6ViWyJdMsTakMIKRHHd2OtIXgIlUNLLd3hrXx0Q6BbD8Q2/U Pob7/w3MRRAosKBhl85IznNWS1Ade2z4b9wDz6ZxWh6pmwq9sCkKa5IuZ8R5UGl+fPLy 9lAYfyzyBi7xupDjYhiEenPpU6/VRZYpE+YsHl1bGcacdJ7OiFiC3uHzFcTDB7Rxek0E dDLlIQw926hTbQD9TH0r0Yw6w5g2fluTWCrhHWRX7C9fK4fov+HD2DExI25K4P+/uEBO xk8Hnz8OrdGTwnA8GsTJhtSbPe8HOjBUU6zudtqe+Sk3jdrwISymLUn9Dlr9O9zBiHRz DMsA== 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=pok2ezpPoFHplItpn6yU0uLbkFeNjqWMvxLnAUgQqjk=; b=P0ue7IYT3+Z45KPNsP+1jOQh873uWeSG7ciIfjB3LI8gGWh/M7riulRVcSO0jNQMUe uHuRHX8ma8FssEPEl8lKYx+IR3eMsditY9YQR3nSiSUkKnrx0vJMZmHPVJObsaGzEqs1 bvS8JU4tOSeJB9aEbMbQrc3mbmot5EP2dxqgXHrx2e3iuJPKDzuu5rpGP4gYNIEZVWqX rOJvY/V4Yk4r1JRN4Ua+ei1epF9X9sdQaG093s2Xa9n6GJoMyuuzKzLQEc/oHHWar7dc psxl8zu0qEthfrPLZcgSkwQ+NoZsPIwfXsD6uYldTVcWvrSw2YhGu10AUsFCJP/qVhW6 7hfA== X-Gm-Message-State: AKGB3mL6PaR12wB+f2yGSoPHgXRE8cnV45HiD1KGNgXeK0aMPpDzPIiE dSO8bJLwYM8ypggXlo6G95+T97eWy3NYXMnk5RvfZA== X-Google-Smtp-Source: ACJfBos10moNB3SdjdbsYkll4fPeyG1D5AwJBzZI+em/vXEVfUCvbryKHRcqDZabLbMUXFmy8gsWcrJVmFyBA/Y73rs= X-Received: by 10.36.77.143 with SMTP id l137mr30761881itb.50.1514243765858; Mon, 25 Dec 2017 15:16:05 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.108.204 with HTTP; Mon, 25 Dec 2017 15:16:05 -0800 (PST) X-Originating-IP: [2603:300b:6:5100:1052:acc7:f9de:2b6d] In-Reply-To: <20171225224458.e925f49181221a2315a1974f@bidouilliste.com> References: <20171225224458.e925f49181221a2315a1974f@bidouilliste.com> From: Warner Losh Date: Mon, 25 Dec 2017 16:16:05 -0700 X-Google-Sender-Auth: 3FmxZSFcGxmknl0CdBf2ZiV5kC0 Message-ID: Subject: Re: devmatch(8) committed .... To: Emmanuel Vadot Cc: "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Dec 2017 23:16:07 -0000 On Mon, Dec 25, 2017 at 2:44 PM, Emmanuel Vadot wrote: > > Hello Warner, > > On Mon, 25 Dec 2017 11:57:10 -0700 > Warner Losh wrote: > > > I've committed devmatch(8) to the tree in r327176. It's a building block > > for automating the loading of modules. While we can load modules today by > > adding FOO_load=YES to loader.conf, there's no easy way to load only the > > modules you need based on the hardware you have in the system. > devmatch(8) > > provides the base framework to allow one to do that. It does this my > > looking at the PNP tables recorded in /boot/kernel/linker.hints. > > > > The version I've committed doesn't have the devd nor the rc.d > integration. > > I've committed it for people to play with and give me feedback while > those > > parts are finalized (and while other bugs are fixed). I don't intend to > > commit them until the kinks are worked out. > > > > Some notes: > > > > (1) You'll need a newly built kernel. Older kernels have minor bugs that > > allowed the terminating sentinel to be included in linker hints. All > known > > oens, at least for amd64, have been fixed. > > (2) Lots and lots of drivers need to have their plug and play tables > > decorated. This is where I need people's help. I'll be writing up > something > > for those that want to help. ISAPNP, PC Card and USB drivers already have > > this data. A few PCI drivers have it, and almost no ACPI drivers. The > data > > is generally there, just not properly decorated for devmatch(8) and > > kldxref(8) to do their thing. > > (3) There's an issue with the USB pnp data. It's too long for the current > > devinfo(3) interfaces. I have fixes in the works to correct this. I could > > just bump the limits, but I want to do something more general and long > term. > > (4) The end game for this is a GENERIC with most of the drivers removed > > that loads drivers automatically. Bootable storage drivers will have to > > remain for now until the loader can make use of this code.This is why the > > warning about hinted ISA devices went into the tree this week. > > (5) modules will print more than once. also the if_em/if_igb driver is a > > hard link so both of those will always print. > > > > Please send me your feedback. Happy Holidays! > > > > Warner > > This is all excellent news I can't wait to try. > > I've not currently started to look at the code but have you thought of > fdt based system ? I would love a minimal GENERIC arm/arm64 kernel with > everything else in modules. > I know we still have to do a lot of work in the arm world to make > almost everything usable in module form. > It's completely bus agnostic. There's no code in devmatch() that knows anything at all about any specific bus. fdt is easier than most because it's just a simple string compare and several of the drivers are already properly decorated. Warner From owner-freebsd-hackers@freebsd.org Mon Dec 25 23:56:25 2017 Return-Path: Delivered-To: freebsd-hackers@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 9CCBDE82C7B; Mon, 25 Dec 2017 23:56:25 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (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 EE51079001; Mon, 25 Dec 2017 23:56:21 +0000 (UTC) (envelope-from kaduk@mit.edu) X-AuditID: 1209190f-c8dff70000003990-47-5a41901c401c Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id A1.1E.14736.C10914A5; Mon, 25 Dec 2017 18:56:12 -0500 (EST) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id vBPNuAGT021437; Mon, 25 Dec 2017 18:56:11 -0500 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id vBPNu6hN017279 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 25 Dec 2017 18:56:09 -0500 Date: Mon, 25 Dec 2017 17:56:07 -0600 From: Benjamin Kaduk To: freebsd-hackers@FreeBSD.org Cc: freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org Subject: FreeBSD Quarterly Status Report - Third Quarter 2017 Message-ID: <20171225235606.GE59505@kduck.kaduk.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="DSayHWYpDlRfCAAQ" Content-Disposition: inline User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrFKsWRmVeSWpSXmKPExsUixCmqrCszwTHKYEe7gsWua6fZLea8+cBk sX3zP0aLw81CDiweMz7NZwlgjOKySUnNySxLLdK3S+DK+Nw3naXg9T6mip0n/zM3MD79ydjF yMkhIWAiceXka7YuRi4OIYHFTBIrf/xihXA2Mko8+j2fHcK5yiRxZs1sNpAWFgFViWs/v4HZ bAJqEutXXGMGsUUE5CX2Nb1nB7GZBawl/j1oBIsLC9hK9H9dClbPC7Su6/lcKFtQ4uTMJywQ 9WUSL243AtkcQLa0xPJ/HCBhUQFlib19h9gnMPLNQtIxC0nHLIQOiLCOxM6td9gwhLUlli18 zQxh20qsW/eeZQEj+ypG2ZTcKt3cxMyc4tRk3eLkxLy81CJdE73czBK91JTSTYzgAJfk38E4 p8H7EKMAB6MSD++BCMcoIdbEsuLK3EOMkhxMSqK8ZdMcooT4kvJTKjMSizPii0pzUosPMaoA 7Xq0YfUFRimWvPy8VCURXmeQOt6UxMqq1KJ8mDJpDhYlcV53E+0oIYH0xJLU7NTUgtQimKwM B4eSBK9rP9BOwaLU9NSKtMycEoQ0EwfnIUYJDh6g4fNBaniLCxJzizPTIfKnGMM5jm26/IeJ 48CEK0Dy1MPbQPLRjbtAcsX/e0Dy2czXDcwc845/a2LmOPT7UCuzENitUuK8e0DGCYCMyyjN g9sISoIS2ftrXjGKAwNDmLcapIoHmEDhdr4COocJ6Jx0T3uQc0oSEVJSDYw7L+lxTmlL/9p/ POBp35/AsDXidwJNYstW/tSO+Frc0rvo1M3J52YvOnunkPfTqe5FSXov2yI6ziyO1l5ioMrc 9FPgQ+u2Rbm+1VW5Z5z3nVx+YmOHdbCL962FvfNa1otMTFjn80j43t6///tbf9b/VFY0LjRd VzRN7czE1becllQ3CdlsPMyuxFKckWioxVxUnAgAhkbwcV0DAAA= X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Dec 2017 23:56:25 -0000 --DSayHWYpDlRfCAAQ Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable FreeBSD Project Quarterly Status Report - 3rd Quarter 2017 This quarter's FreeBSD developments continue to provide excitement and promise for further developments. I myself have a soft spot for manual pages, so it is especially good to see that we have gained some documentation for writing them (and I hope that this will translate to more and improved manual pages in the future!). The core@ entry is also of particular note, with the introduction of the FCP process and the recognition of the first non-committer FreeBSD Project Member (and more). Read on to find out more about these, as well as improved support for the AMD Zen family of processors (e.g., Ryzen), and a whole lot more! --Benjamin Kaduk __________________________________________________________________ The deadline for submissions covering the period from October to December 2017 is January 14, 2017. __________________________________________________________________ FreeBSD Team Reports * FreeBSD Release Engineering Team * Ports Collection * The FreeBSD Core Team * The FreeBSD Foundation Projects * FreeBSD CI Kernel * Intel 10G iflib Driver Update * Intel iWARP Support * pNFS Server Plan B Architectures * AMD Zen (family 17h) support Userland Programs * Updates to GDB Ports * FreeBSDDesktop * OpenJFX 8 * Puppet Documentation * Absolute FreeBSD, 3rd Edition * Manual Pages Third-Party Projects * The nosh Project __________________________________________________________________ FreeBSD Team Reports Entries from the various official and semi-official teams, as found in the Administration Page. FreeBSD Release Engineering Team Links FreeBSD 11.1-RELEASE Announcement URL: https://www.FreeBSD.org/releases/11.1R/announce.html FreeBSD 10.4-RELEASE Schedule URL: https://www.FreeBSD.org/releases/10.4R/schedule.html FreeBSD Development Snapshots URL: https://download.FreeBSD.org/ftp/snapshots/ISO-IMAGES/ Contact: FreeBSD Release Engineering Team The FreeBSD Release Engineering Team is responsible for setting and publishing release schedules for official project releases of FreeBSD, announcing code freezes, and maintaining the respective branches, among other things. The FreeBSD Release Engineering Team continued finalizing the 11.1-RELEASE cycle, with the final release builds starting on July 21 and the official release announcement email sent on July 26. Thank you to everyone who helped test 11.1-RELEASE, ensuring its quality and stability. [1] FreeBSD 11.1-RELEASE is the second release from the stable/11 branch. Additionally, the FreeBSD Release Engineering Team started the 10.4-RELEASE cycle, with the code slush starting on July 28. With the final release build expected to start on September 29 and the official announcement overlapping the end of the quarter, everything is on schedule as of this writing. [2] FreeBSD 10.4-RELEASE will be the fifth release from the stable/10 branch, and is planned to be the final release of the 10.x series. This project was sponsored by The FreeBSD Foundation [1]. This project was sponsored in part by The FreeBSD Foundation [2]. __________________________________________________________________ Ports Collection Links About FreeBSD Ports URL: https://www.FreeBSD.org/ports/ Contributing to Ports URL: https://www.freebsd.org/doc/en_US.ISO8859-1/articles/contributing/= ports-contributing.html FreeBSD Ports Monitoring URL: http://portsmon.freebsd.org/index.html Ports Management Team Website URL: https://www.freebsd.org/portmgr/index.html FreeBSD portmgr on Twitter (@freebsd_portmgr) URL: https://twitter.com/freebsd_portmgr/ FreeBSD Ports Management Team on Facebook URL: https://www.facebook.com/portmgr FreeBSD Ports Management Team on Google+ URL: https://plus.google.com/communities/108335846196454338383 Contact: Ren=E9 Ladan Contact: FreeBSD Ports Management Team The Ports Collection now features over 31,600 ports. There are currently 2671 problem reports, of which 718 are unassigned. This quarter saw almost 5,900 commits from 175 committers. The number of open PRs grew compared to last quarter, and outpaced the number of changes. This quarter, we welcomed Zach Leslie (zleslie@), Luca Pizzamiglio (pizzamig@), Craig Leres (leres@), Adriaan de Groot (adridg@), and Dave Cottlehuber (dch@) as new committers. The commit bits of the following committers were taken in for safekeeping: alonso@ after 19 months of inactivity, rpaulo@ per his request, and ache@ after he passed away. Despite several tries and changing mentors, kami@ lacked interest in completing his mentorship, so his commit bit was also taken in for safekeeping. On the infrastructure side, two USES values were removed because they outlived their usefulness: * execinfo: libexecinfo is now available in the base system of all supported FreeBSD versions * twisted: there is only one Twisted port left The default version of GCC was bumped from 5 to 6. Firefox was updated to version 56.0 and Chromium to version 61.0.3163.100. The version of pkg itself was updated to 1.10.1. During this quarter, antoine@ performed 28 exp-runs to test version updates of major ports, improving USE_GITHUB and SHEBANG_FILES, and API changes to the base system. This quarter, the foundation for ports "flavors" was committed, though more development and testing will be performed in the coming quarter before it goes live. Open tasks: 1. The PR load needs more attention, as the number of open PRs has started to increase again. __________________________________________________________________ The FreeBSD Core Team Contact: FreeBSD Core Team The new "FreeBSD Community Process" was drafted during BSDCan earlier this year. The first such document, FCP 0, defines how the whole process works. After some time for discussion and revision, FCP 0 was voted on and accepted by core, following the procedure laid down within that document. Currently the use of FCPs is entirely optional; we shall see how the community begins to adopt their usage and evolve the process based on experience. A draft update to the Code of Conduct has been prepared by the advisory committee. Core is currently reviewing the text, and will soon vote on accepting it. Core is keen to avoid the trap of "rules lawyering". At the moment, the feeling is that we need to add a preamble to the CoC to articulate the goals of the project and to act as a general guide to the exercise of the code. This quarter has been quite a busy one concerning changes to the roster of committers and project members. We have elected our first new Project Member: John Hixson, who will be familiar from many conferences where he has given presentations and ably represented iXsystems. A second proposed Project Member was not accepted by core, but only because core felt that Fedor Uporov really deserved a commit bit instead. In addition to Fedor Uporov, please also welcome (in no particular order) Matt Joras, Marcin Wojtas, Chuck Tuffli, Ilya Bakulin and Alex Richardson as brand-new committers. We have also awarded Steven Hurd and Eugene Grosbein src commit bits to go with their existing ports bits. Welcome back Gordon Tetlow as a src committer, essential for his new role within secteam. Eric Davis and Rui Paulo have both decided to hang up their commit bits: we wish them well in their future endeavours. Finally, we must report the sad death of Andrey Chernov, who will be sorely missed by his colleagues and collaborators. Andrey's death has highlighted another question which is only going to become more complex over time. Keeping track of copyrights is already hard enough within a mature source tree with many contributors, such as the FreeBSD sources. Now we need to consider trying to keep track of the heirs and beneficiaries of contributors who have sadly passed away. Core will consult with the Foundation legal team to discuss possible approaches to alleviate this. There have been complaints that the workings of Core are being kept overly confidential, and that consequently the majority of the project has too little idea of what is going on. This is certainly not intentional by Core, and we are keen to open up Core's business to more general community scrutiny as far as seems reasonable. Core dealt with a number of licensing questions: * When upstreaming patches and other original works to VirtualBox or other Oracle properties, pragmatically it works best to provide them under the terms of the MIT license (one of two opensource licenses accepted by Oracle). Of course, this only applies to work upstreamed by or with the permission of the original author. * The Viking software license is sufficiently BSD-like that magic constants from their drivers can be used in FreeBSD code. * There is no separate register of deviations from the allowed BSD-like licenses in the source tree: any code in the tree under other than BSD-like license terms can be assumed to have been approved by core. * At the moment the FreeBSD copyright requirement to include the copyright notice in redistributions in binary form is satisfied by making the FreeBSD sources, with all of the detailed copyright information included in the different source code files, available alongside pre-compiled system images. However, this does not necessarily meet the needs of downstream projects based on FreeBSD, and given the new "packaged base", adding per-package licensing metadata in a way similar to how the Ports Collection works is under consideration as an alternative mechanism. Concerns were raised regarding the pending HardenedBSD entry in the previous quarterly report prior to publication. The FreeBSD project welcomes reports from separate (but derived) projects in quarterly reports and has included similar reports in the past from other projects (such as TrueOS and pfSense). The HardenedBSD report was edited for length and to concentrate on activities during the quarter in question. Amazon is proposing to set up mirrors of the freebsd-update and pkg servers within AWS in order to provide faster access for EC2 users. These mirrors will be publicly accessible, but the expectation is that use will primarily be from within EC2. FreeBSD AMIs will have a preset configuration that references the Amazon servers. The old, long-deprecated, and insecure "r-commands" (rsh, rlogin, rcp) are being removed from the base system for 12.0-RELEASE. Notice of this was added to the man pages and release notes in time for 11.1-RELEASE and 10.4-RELEASE. Anyone requiring these commands for backwards compatibility can use the new net/bsdrcmds port. Work to replace Heimdal Kerberos in base with the more widely compatible MIT Kerberos has begun in a new projects/krb5 branch. This should not fall afoul of any US cryptography export regulations: the project is required to notify the US government that cryptographic software can be downloaded from FreeBSD servers, and this already covers MIT Kerberos, already available within ports. A number of Bay Area FreeBSD User Group-related domain names are being given up by their original owner. The current BAFUG organisers have been made aware. Core has voted on a change to the Doceng voting rules to provide for a "did not vote" status during doceng voting similar to how portmgr and core voting operates. The current requirement for all five members of doceng to register a vote on issues was proving to be a significant bottleneck. __________________________________________________________________ The FreeBSD Foundation Links FreeBSD Foundation Website URL: https://www.FreeBSDFoundation.org/ FreeBSD Foundation Quarterly Newsletter URL: https://www.FreeBSDfoundation.org/wp-content/uploads/2017/08/FreeB= SD-Foundation-July-August-2017-Update.pdf Contact: Deb Goodkin The FreeBSD Foundation is a 501(c)(3) non-profit organization dedicated to supporting and promoting the FreeBSD Project and community worldwide. Funding comes from individual and corporate donations and is used to fund and manage software development projects, conferences and developer summits, and provide travel grants to FreeBSD contributors. The Foundation purchases and supports hardware to improve and maintain FreeBSD infrastructure and provides full-time Release Engineering support; publishes marketing material to promote, educate, and advocate for the FreeBSD Project; facilitates collaboration between commercial vendors and FreeBSD developers; and finally, represents the FreeBSD Project in executing contracts, license agreements, and other legal arrangements that require a recognized legal entity. Here are some highlights of what we did to help FreeBSD last quarter: Fundraising Efforts Our work is 100% funded by your donations. This year we have raised over $860,000 from over 500 donors. Our 2017 fundraising goal is $1,250,00 and we are continuing to work hard to meet and exceed this goal! Please consider making a donation to help us continue and increase our support for FreeBSD: https://www.FreeBSDfoundation.org/donate/. We also have a new Partnership Program, to provide more benefits for our larger commercial donors. Find out more information at https://www.FreeBSDfoundation.org/FreeBSD-foundation-partnership-program/ and share with your companies! OS Improvements The Foundation improves the FreeBSD operating system by employing our technical staff to maintain and improve critical kernel subsystems, add features and functionality, and fix problems. This also includes funding separate project grants like the arm64 port, blacklistd access control daemon, and the integration of VIMAGE support, to make sure that FreeBSD remains a viable solution for research, education, computing, products and more. We kicked off or continued the following projects last quarter: * OpenZFS RAID-Z Expansion project * Broadcom Wi-Fi infrastructural improvements (bhnd(4) driver) * Headless mode out-of-the-box for the Beaglebone Black * Extending bhyve/ARMv7 features * Porting bhyve/ARM to an ARMv8 platform Having software developers on staff has allowed us to jump in and work directly on projects to improve FreeBSD like: * ZFS improvements * New Intel server support * kqueue(2) updates * 64-bit inode support * Stack guard * Kernel Undefined Behavior Sanitizer * Toolchain projects * i915 driver investigation * NVDIMM support in acpiconf(8) * Continuous integration dashboard (web page and physical hardware) * FAT filesystem support in makefs(8) Staff and board members continued hosting bi-weekly conference calls to facilitate efforts for individuals to collaborate on different technologies. Release Engineering The Foundation provides a full-time staff member to lead the release engineering efforts. This has provided timely and reliable releases over the last few years. Last quarter, our full-time staff member worked with the FreeBSD Release Engineering and Security Teams to finalize 11.1-RELEASE. He also supported the 10.4 release effort, and has continued producing 10-STABLE, 11-STABLE, and 12-CURRENT development snapshot builds throughout the quarter. At the vBSDCon Developer Summit, he gave a presentation on the state of the release engineering team. You can find out more about the support we provided to the Release Engineering Team by reading their status update in this report. Supporting FreeBSD Infrastructure The Foundation provides hardware and support to improve the FreeBSD infrastructure. Last quarter, we continued supporting FreeBSD hardware located around the world. FreeBSD Advocacy and Education A large part of our efforts are dedicated to advocating for the Project. This includes promoting work being done by others with FreeBSD; producing advocacy literature to teach people about FreeBSD and help make the path to starting using FreeBSD or contributing to the Project easier; and attending and getting other FreeBSD contributors to volunteer to run FreeBSD events, staff FreeBSD tables, and give FreeBSD presentations. The FreeBSD Foundation sponsors many conferences, events, and summits around the globe. These events can be BSD-related, open source, or technology events geared towards underrepresented groups. We support the FreeBSD-focused events to help provide a venue for sharing knowledge, to work together on projects, and to facilitate collaboration between developers and commercial users. This all helps provide a healthy ecosystem. We support the non-FreeBSD events to promote and raise awareness of FreeBSD, to increase the use of FreeBSD in different applications, and to recruit more contributors to the Project. Here is a list highlighting some of the advocacy and education work we did last quarter: * Organized and ran the Essen FreeBSD Hackathon in Essen Germany * Sponsored and participated in the FreeBSD Developer Summit BSDCam, in Cambridge, England * Represented FreeBSD at the ARM Partner Meeting * Presented and taught about FreeBSD at SdNOG 4 in Khartoum, Sudan * Sponsored and gave presentations and tutorials at EuroBSDCon in Paris, France * Organized and ran the Paris FreeBSD Developer Summit * Organized and ran the FreeBSD Developer Summit at vBSDCon * Sponsored and attended vBSDCon * Proved travel grants to FreeBSD contributors to attend the above events. * Sponsored the 2017 USENIX Security Symposium in Vancouver BC as an Industry Partner * Provided FreeBSD advocacy material * Sponsored the 2017 USENIX Annual Technical Conference in Santa Clara, CA as an Industry Partner We continued producing FreeBSD advocacy material to help people promote FreeBSD around the world. We help educate the world about FreeBSD by publishing the professionally produced FreeBSD Journal. Last quarter we published the July/August issue that you can find at https://www.FreeBSDfoundation.org/journal/. You can find out more about events we attended and upcoming events at https://www.FreeBSDfoundation.org/news-and-events/. Legal/FreeBSD IP The Foundation owns the FreeBSD trademarks, and it is our responsibility to protect them. We also provide legal support for the core team to investigate questions that arise. Go to http://www.FreeBSDfoundation.org to find out how we support FreeBSD and how we can help you! __________________________________________________________________ Projects Projects that span multiple categories, from the kernel and userspace to the Ports Collection or external projects. FreeBSD CI Links freebsd-ci Repository URL: https://github.com/freebsd/freebsd-ci freebsd-testing Mailing List URL: https://lists.FreeBSD.org/mailman/listinfo/freebsd-testing FreeBSD Jenkins Instance URL: http://ci.FreeBSD.org Contact: Jenkins Admins The FreeBSD CI team runs various continuous integration solutions for FreeBSD, regularly checking that the current state of the Subversion repository can successfully build, and performing various tests and analysis upon the build results. We have introduced a DTrace test pipeline, with the results and artifacts available at: * https://ci.FreeBSD.org/job/FreeBSD-head-amd64-dtrace_test/ * https://artifact.ci.FreeBSD.org/dtrace-test/ We had team meetings at two developer summits during Q3: * BSDcam * EuroBSDCon Open tasks: 1. Fix the failing test cases and builds. 2. Create builds for additional architectures. 3. Add more tests. 4. The additional TODO items listed at https://wiki.FreeBSD.org/Jenkins/TODO . __________________________________________________________________ Kernel Updates to kernel subsystems/features, driver support, filesystems, and more. Intel 10G iflib Driver Update Links ixgbe iflib Conversion URL: https://reviews.FreeBSD.org/D11727 Contact: Chris Galazka Contact: Piotr Pietruszewski The ix and ixv network interface drivers support a variety of Intel network interfaces, with line speeds at 10 Gbit/second. This quarter, with the help of Matt Macy and Sean Bruno (among others), we have submitted a review in Phabricator for the conversion of the ixgbe driver to use the new (and evolving) iflib framework. Stay tuned for the conversion of the 40G driver (ixl), as it is currently being ported to use iflib. Open tasks: 1. Additional testing. __________________________________________________________________ Intel iWARP Support Links iWARP for ixl URL: https://reviews.FreeBSD.org/D11378 Contact: Bartosz Sobczak iWARP is a protocol suite that enables efficient movement of data across the network, building on Remote Direct Memory Access, Direct Data Placement, and Marker PDU Aligned Framing. It endeavors to avoid unnecessary (local) data copies and to offload work from the main CPU to dedicated hardware. An initial commit adding iWARP support for the Intel X722 family of network adapters is under review. This is an important step towards introducing full iWARP support on systems equipped with Intel C620 Series Chipsets. Currently, with the iw_ixl driver, only the kVerbs API is supported. Open tasks: 1. Additional testing. __________________________________________________________________ pNFS Server Plan B Links Instructions for Testing URL: http://people.FreeBSD.org/~rmacklem/pnfs-planb-setup.txt Contact: Rick Macklem A pNFS server allows an NFS service to be spread over multiple servers, separating the MetaData operations from the Data operations (Read and Write). This project will add the ability to use FreeBSD systems to create a pNFS service consisting of a single MetaData Server plus a set of Data Servers. The Data Servers can be mirrored, so that redundant copies of the file data are maintained. The support for non-mirrored Data Servers is now believed to be complete. Support for mirrored Data Servers using the Flexible File Layout, which will soon be published as an RFC, is implemented. However, there is still significant work to be done, since the current implementation of mirrored Data Servers does not handle failed Data Servers or their resilvering/recovery. It is hoped that support for failure/recovery of Data Servers will be implemented in the next six months. The patched FreeBSD sources may now be accessed for testing via either Subversion or downloading a gzipped tarball. They consist of a patched kernel and nfsd and can be used on any FreeBSD 11 or later system. The installation procedure is covered in the linked document. Open tasks: 1. Testing by others will be needed, now that the implementation is available. 2. Implementation and testing of mirror failure/recovery. __________________________________________________________________ Architectures Updating platform-specific features and bringing in support for new hardware platforms. AMD Zen (family 17h) support Contact: Conrad Meyer cem@FreeBSD.org <> This quarter, a bit of work was done to enhance platform support for AMD Zen (Ryzen, Threadripper, Epyc) processors: * The CPU topology detection code was enhanced to properly detect Zen dies and CPU Complexes. This gives the scheduler more locality information to use when making scheduling decisions. * The x86 topology analysis was enhanced to report dies and CPU Complexes, in addition to the existing reporting on packages, cores, and threads. An example of the new output is FreeBSD/SMP: 1 package(s) x 2 groups x 2 cache groups x 4 core(s) x 2 hardware threads. * The amdsmn(4) driver for accessing SMN (System Management Network) registers was added. * CPU temperature monitoring support for Zen was added to amdtemp(4). * In cpufreq(4): + Added support for decoding Zen P-state information from Machine State Registers (which is usually not necessary, since it is largely redundant with ACPI P-state information, but is potentially useful) + Work around the apparent Ryzen inability to achieve the P1 state by not busying cores waiting to transition to it * The intpm(4) smbus driver was fixed to attach to the AMD FCH (Fusion Controller Hub). * All MCA banks are now enabled and monitored on Zen CPUs. * Feature-bit decoding was added for: CLZERO, SVM features, and RAS capabilities. * SHA intrinsic support was added to the aesni(4) driver. Ryzen is currently the only desktop processor to feature these intrinsics. Support for these intrinsics is also present in Intel's Goldmont line of low-end SoCs. Overall, Zen is now a very usable platform for x86 workstations and servers. This project was sponsored by Dell EMC Isilon. Open tasks: 1. Add HWPMC support for the new performance counters avilable on the Zen architecture. 2. Add support for the CCP (Crypto Co-Processor). __________________________________________________________________ Userland Programs Changes affecting the base system and programs in it. Updates to GDB Contact: John Baldwin Contact: Luca Pizzamiglio The devel/gdb port has been updated to GDB 8.0.1. Support for FreeBSD/aarch64 userland binaries has been committed upstream. These patches, along with support for debugging FreeBSD/aarch64 kernels, have been committed to the port. Upstream patches adding improved support for FreeBSD/arm userland binaries are currently in review. FreeBSD 12 has recently grown support for debugging VFP registers via ptrace() and core dumps as part of this work. Support for FreeBSD/arm kernels will be added to the port after the upstream patches are added to the port. Support for $_siginfo has been committed upstream. This uses the recently added NT_LWPINFO note to extract signal information from process cores. Hangs that occured when GDB's kill command was used were fixed in FreeBSD in r313992. Open tasks: 1. Figure out why the powerpc kgdb targets are not able to unwind the stack past the initial frame. 2. Test support for sparc64 binaries and kernels. 3. Add support for debugging powerpc vector registers. 4. Implement info proc commands. 5. Implement info os commands. __________________________________________________________________ Ports Changes affecting the Ports Collection, whether sweeping changes that touch most of the tree, or individual ports themselves. FreeBSDDesktop Links FreeBSDDesktop on GitHub URL: https://github.com/FreeBSDDesktop/ Contact: Johannes Dieterich Contact: Mark Johnston Contact: Hans Petter Selasky Contact: Matthew Macy The FreeBSDDesktop team is happy to announce the availability of graphics/drm-next-kmod. This port for FreeBSD-CURRENT (amd64) provides support for the amdgpu, i915, and radeon DRM modules using the linuxkpi compatibility framework. The port currently corresponds to the DRM from Linux 4.9 and is in an experimental state. It works reliably for many testers with modern GPU hardware (AMD HD7000 series/Tahiti to Polaris and Intel HD3000/Sandy Bridge to Skylake). Broader testing and reporting/fixing of bugs is appreciated. Open tasks: 1. Resolve issues that cause radeonkms and amdgpu to fail with EFI boot (though there is a workaround available). 2. Upgrade to Linux 4.10 and higher DRM versions. 3. Get feedback from broader testing. __________________________________________________________________ OpenJFX 8 Links OpenJFX Wiki URL: https://wiki.openjdk.java.net/display/OpenJFX/Main java/openjfx8-devel URL: https://www.freshports.org/java/openjfx8-devel java/openjfx8-scenebuilder URL: https://www.freshports.org/java/openjfx8-scenebuilder AsciidocFX URL: https://github.com/asciidocfx/AsciidocFX Contact: Tobias Kortkamp OpenJFX is an open source, next generation, client application platform for desktop and embedded systems, based on JavaSE. This quarter, the OpenJFX port was reworked and has received some significant improvements. More modules are being built. With the new web module we gain support for applications that have their own builtin web browser such as AsciidocFX. The new media module allows JavaFX applications to play audio and video files. A port of the JavaFX scenebuilder, a RAD tool for building JavaFX scenes, was added to the ports tree. The OpenGL Prism backend for GPU acceleration was enabled by default. From a mainainer's and contributor's perspective, the port was simplified by moving all FreeBSD-local patches to the ports tree and fetching the upstream sources directly, instead of using a separate repository for them. Open tasks: 1. Upstream some of the patches in the Ports Collection. __________________________________________________________________ Puppet Links Puppetlab's FreeBSD Slack Channel URL: https://puppetcommunity.slack.com/messages/C6CK0UGB1/ Contact: Puppet Team This summer has seen the creation of a puppet@ team to help maintain the approximately 30 Puppet-related ports in the FreeBSD Ports Collection. These ports were previously maintained by various committers, and from time to time the distributed maintainership introduced some delays when updating a port, due to the need to wait for a maintainer's approval for a related change to a different port. Puppet 5 is now in the ports tree (as sysutils/puppet5). The C++ version of Facter (sysutils/facter) got a lot of attention and is now a drop-in replacement for the previous Ruby version (sysutils/rubygem-facter); it is the default facts source for the Puppet 5 port. Work continues on bringing in Puppetserver 5 to the ports tree, and on keeping all the ports up-to-date. Open tasks: 1. The pkg package provider has some minor issues (it breaks things when no repos are configured, and is not working properly from the context of the MCollective package agent). 2. The databases/puppetdb[345] and sysutils/puppetserver[45] ports rely on Clojure and Java, and download compiled jar files instead of building them from source. __________________________________________________________________ Documentation Noteworthy changes in the documentation tree or new external books/documents. Absolute FreeBSD, 3rd Edition Links Official Announcement URL: https://blather.michaelwlucas.com/archives/3020 Contact: Michael Lucas The first draft of the third edition of Absolute FreeBSD is finished. It is 220,200 words, or roughly enough to stun a medium-sized ox. It's on target to be in print before BSDCan 2018. Open tasks: 1. Stare at the wall blankly for a few days. 2. Fix all the problems pointed out by dozens of community reviewers. 3. Fix all the problems pointed out by John Baldwin, tech reviewer extraordinaire. 4. Editing. Copyediting. Page layout. Page editing. Re-editing. Indexing. Edits discovered by indexer. 5. Pre-orders should open some time next year. 6. Restrain myself from strangling people who ask when the fourth edition is coming. __________________________________________________________________ Manual Pages Links FreeBSD Documentation Project Primer URL: https://www.freebsd.org/doc/en_US.ISO8859-1/books/fdp-primer/ Contact: Warren Block Over the last year, interest has increased in manual pages, in large part due to excellent infrastructure work by Baptiste Daroussin and others, and promotion by George Neville-Neil and others. This increased interest has been both gratifying and problematic. Our man pages are underappreciated gems, but we have sadly lacked any substantial documentation on how to write new ones. In September, I added a new chapter to the FreeBSD Documentation Project Primer describing the basics of creating a man page. It includes descriptions of the markup, section structure, recommended optional material such as examples, and sample templates for the most common types of man pages. The Resources section includes links to several external resources, including the excellent Practical UNIX Manuals: mdoc. While this chapter is not a full tutorial, it does begin to fill in a large gap in our documentation resources and provide a starting point from which to grow. Open tasks: 1. Add more explanation and examples of markup usage. 2. Expand the sample templates with additional desired standard features, like an EXAMPLES section. 3. Add more sample templates. __________________________________________________________________ Third-Party Projects Many projects build upon FreeBSD or incorporate components of FreeBSD into their project. As these projects may be of interest to the broader FreeBSD community, we sometimes include brief updates submitted by these projects in our quarterly report. The FreeBSD project makes no representation as to the accuracy or veracity of any claims in these submissions. The nosh Project Links Introduction URL: http://jdebp.eu./Softwares/nosh/ FreeBSD Binary Packages URL: http://jdebp.eu./Softwares/nosh/freebsd-binary-packages.html Installation How-To URL: http://jdebp.eu./Softwares/nosh/timorous-admin-installation-how-to= =2Ehtml Roadmap URL: http://jdebp.eu./Softwares/nosh/roadmap.html A Slightly Outdated User Guide URL: http://jdebp.eu./Softwares/nosh/guide/index.html Archnosh URL: http://framagit.org/taca/archnosh Contact: Jonathan de Boyne Pollard The nosh project is a suite of system-level utilities for initializing, running, and shutting down BSD systems; and for managing daemons, terminals, and logging. It attempts to supersede BSD init, the Mewburn rc.d system, and OpenRC as used on FreeBSD and TrueOS, drawing inspiration from Solaris SMF for named milestones, daemontools-encore for service control/status mechanisms, UCSPI, and IBM AIX for separated service and system management. It includes a range of compatibility mechanisms, including shims for familiar commands from other systems, and an automatic import mechanism that takes existing configuration data from /etc/fstab, /etc/rc.conf{,.local}, /etc/ttys, and elsewhere, applying them to its native service definitions and creating additional native services. It is portable (including to Linux) and composable, it provides a migration path from the world of systemd Linux, and it does not require new kernel APIs. It provides clean service environments, orderings and dependencies between services, parallelized startup and shutdown (including fsck), strictly size-capped and autorotated logging, the service manager as a "subreaper", and uses kevent(2) for event-driven parallelism. Since the last status report, in December 2015, the project has seen: restructured and finer-grained packaging that has fewer conflicts with other toolsets; the addition of zsh completion files; improvements to the virtual terminal subsystem, keyboard map, mouse support, and ugen and DECSCUSR support; RFC 5424/5426 remote logging support; replacement of libkqueue and the C library's environment handling functions; several new helper commands; support for Java VM autolocation; improved socket-passing code; an extended status API and "one-shot" service support; additional pre-supplied service bundles; support for service aliases; improved handling of per-user D-Bus services; improved importing of MySQL, MariaDB, Percona, and OpenVPN services; improved configuration import support; and extensive additions to the nosh Guide. On the recently updated roadmap you can see plans for even more documentation, continuing the work to extend the capabilities of the networking subsystem, and the scant handful of rc.d-related items remaining. There are also some ideas still in the speculative or planning phases, including work that may depend on incorporating nosh support into other software. Open tasks: 1. Improve Ansible and SaltStack integration (the maintainer of the Arch Linux nosh integration has some ideas). 2. Command-line completions are still needed for bash, csh, and fish. 3. Document convert-systemd-units for use by port maintainers in making packaged service bundles from systemd unit files. 4. nosh could take advantage of several proposed features for the base system: + the boot loader signaling "emergency" and "rescue" modes of operation + adding machine-readable status output to fsck + adding runtime support for more clang-compilable languages in the early bootstrap stage + adding hooks for invoking external configuration import mechanisms __________________________________________________________________ --DSayHWYpDlRfCAAQ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQG3BAABCgAdFiEE2WGV4E2ARf9BYP0XKNmm82TrdRIFAlpBkBAACgkQKNmm82Tr dRJOgwwg5WCG7cNAQURqjmTzoc7Uc9JwYnksJ6dJzrod9rV0ToAqPJzMD+G2TEKX L7IX2yB2IMGFKb6pLRZ9UF6Z3EasSXDwq4H2G8qxe12mK9Oc/yV8rY1YZu6DYLoV czpgzhZbpvDOkjXl7/z4x7NI097Rrh9gj9SO8jZ5g/ufAzfo/qPtt9tNlcxarNI3 TGjN4jFadgbqohI12NO9AnsJO2sKfgDOO5UKbk8r2pcBoQBns2GkftjEiX0xKMc6 ZWxht72aVUtI6gaWLVq2yDSAg8hR86NB+0mib28QXBPL7jGg6cYYwXHRVKYTYMS7 BTqdQMQVva2xDg5KLZA20D+OWb+G4HEAjvMmB7TZeINbFJuLl6NWw/cDJAAR7gxF Z6pyAPSmadkXRlJ4TPzCm8LGJflEOozafv/4bsN6s3v+Fq1SpYVF/v9VwtqL/JxT NsfTzHnE3ZSujXmPM9bAD87VPO5vsrK2G4lYBx8MoVsLpD5asNvPbvJ/Z8nip+Ov dtbK8avd2FqQFQ== =5EQJ -----END PGP SIGNATURE----- --DSayHWYpDlRfCAAQ-- From owner-freebsd-hackers@freebsd.org Tue Dec 26 00:12:54 2017 Return-Path: Delivered-To: freebsd-hackers@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 D258EE8432F; Tue, 26 Dec 2017 00:12:54 +0000 (UTC) (envelope-from aryeh.friedman@gmail.com) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::230]) (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 A2B3279D03; Tue, 26 Dec 2017 00:12:51 +0000 (UTC) (envelope-from aryeh.friedman@gmail.com) Received: by mail-io0-x230.google.com with SMTP id q188so7042874iod.1; Mon, 25 Dec 2017 16:12:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=yYz7/82v+JZ3K8dcoIS12RKIdDqY4l1NYK6OetPJd48=; b=LRsIC8Hp0+lveVWUINcbaeR6Ej0S6e7wVKO/4Y6Ga9uwUWNUvRvEHQTdSt82oL0wy9 FSyaI3fF5y9dm8K8VgoI2PLW/dj2PS2rLUaNwjJ0zgnWsRdOq4MZ15UhwiOftaop6D8Q AEWHr6CGxaPTjvpB4POj439UdtihgXjdH++Eyu7oVR8ncF00IFfNUGycKIsNanP+fM4s KlwOo7iMAkiNb9Z9Au9sTXtPolzTpeAR/HhKjr3zLKoX7BEKgJwv4alP3CTXQUNrv8zn 4buK7VjIsj6cGLCwJNSn7VsPymuzoe6bQuPV22PsxDLPMDeER1l8SoBzEMo9ZP/Nv7PP q0kQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=yYz7/82v+JZ3K8dcoIS12RKIdDqY4l1NYK6OetPJd48=; b=lUWVoRMDD29o+4XmClcNlN+IAsPR2ojqTRRh9kjmAZQuSW8c8z3D0HC9VgS7RusRKM b+M30O4cUr2lXtnUyKA3OwoDGnaoVMsBYGSt1rAKzrHvyN2r/9JganmWnlh6AtI2eCOG bzB20lMJW5c/PSXFxmSHdmmjNCusO/3b2ov78E5mizRFmy0FIA6IxIPoOLpXX8sKk4E+ dbVzAnKAu2FHyuUZURZ12Sp/oN185o5SNUKgW5dtNv6UUr3r0+zlEdyf4Js3aI+Gl2MG eJ4jx0E6mIgcJI/iqAyBx4JoXlUIxbnJmc3CJAFzJP4iUqwc8h63F+5CI8+4M0y/Oa7D hP5A== X-Gm-Message-State: AKGB3mLTtQpmVsWARj7MQLvAvWalNpSHd3PAiKI0TG87g+jCmv7c0hC7 AY3vXOfTciu1+wEDUEvtwBpOgOIG8oVCZiIIIBk= X-Google-Smtp-Source: ACJfBoti/swAPZYdyBKzGHAkYTzPxHXbo90Lf11kQdzk7BT1TMRF5gUsTGRvVNwpmjqiQd16yqkhw3Csc/w529tb45w= X-Received: by 10.107.232.9 with SMTP id f9mr33167601ioh.157.1514247170564; Mon, 25 Dec 2017 16:12:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.36.105.3 with HTTP; Mon, 25 Dec 2017 16:12:50 -0800 (PST) From: Aryeh Friedman Date: Mon, 25 Dec 2017 19:12:50 -0500 Message-ID: Subject: Running dual boot windows inside of bhyve To: "freebsd-virtualization@freebsd.org" , FreeBSD Mailing List , FreeBSD Mailing List Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Dec 2017 00:12:54 -0000 Cross posted to virtualization@, hackers@ and questions. I have a dual boot machine (windows 7 64 bit and fbsd 11.1-RELEASE [amd64]) and want to run the windows partition as a vm in bhyve how would I go about this. Bonus if the process is standalone scriptable so I can add it as a feature of PetiteCloud. -- Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org From owner-freebsd-hackers@freebsd.org Tue Dec 26 00:32:33 2017 Return-Path: Delivered-To: freebsd-hackers@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 1CEF7E85D6E; Tue, 26 Dec 2017 00:32:33 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (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 85A6A7ACCE; Tue, 26 Dec 2017 00:32:32 +0000 (UTC) (envelope-from kaduk@mit.edu) X-AuditID: 12074423-2d1ff70000001b18-ed-5a4197681a50 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id BD.2C.06936.967914A5; Mon, 25 Dec 2017 19:27:21 -0500 (EST) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id vBQ0RJJs027833; Mon, 25 Dec 2017 19:27:20 -0500 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id vBQ0RGMC023187 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 25 Dec 2017 19:27:18 -0500 Date: Mon, 25 Dec 2017 18:27:16 -0600 From: Benjamin Kaduk To: freebsd-hackers@FreeBSD.org Cc: freebsd-current@FreeBSD.org Subject: Call for 2017Q4 quarterly status reports Message-ID: <20171226002716.GG59505@kduck.kaduk.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Rgf3q3z9SdmXC6oT" Content-Disposition: inline User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupgleLIzCtJLcpLzFFi42IR4hTV1s2c7hhl8O2ztsWcNx+YLLZv/sfo wOQx49N8lgDGKC6blNSczLLUIn27BK6MW1MmMRa0CVdM/PONsYHxkEAXIyeHhICJxPW+O6wg tpDAYiaJ9cdFuxi5gOyNjBIz785jhHCuMkl8Of4ZrIpFQFXi5M+XLCA2m4CKREP3ZWYQW0RA XmJf03t2EJsZyP61tQnMFhYwlNizuh2snhdo299Dl1khbEGJkzOfsEDUl0lcm3mXrYuRA8iW llj+jwMkLCqgLLG37xD7BEa+WUg6ZiHpmIXQARHWkrjx7yUThrCtxLp171kWMLKtYpRNya3S zU3MzClOTdYtTk7My0st0jXTy80s0UtNKd3ECApYdhflHYwv+7wPMQpwMCrx8B6IcIwSYk0s K67MPcQoycGkJMpbNs0hSogvKT+lMiOxOCO+qDQntfgQowrQrkcbVl9glGLJy89LVRLhdQap 401JrKxKLcqHKZPmYFES5/Uw0Y4SEkhPLEnNTk0tSC2CycpwcChJ8J6aBrRTsCg1PbUiLTOn BCHNxMF5iFGCgwdo+GuQGt7igsTc4sx0iPwpRl2OZzNfNzALgV0gJc57ZCpQkQBIUUZpHtwc UAKSyN5f84pRHOhFYd5gkFE8wOQFN+kV0BImoCXpnvYgS0oSEVJSDYwe2i+z+wSXPLW8xq19 56LJxiM1fOrtUkk7guRnZu5Km12+adr8p680f5QHOk4w5++wab+0PiMg6cLvhbscNyh33cmZ f0T0gAfvLi3PyFt/PfLXa2tvzxaymBn4ZAdPapH171P1B/nLPznJWAvzh8hbBAasqW+fVLxj ekPEjDXZeeqtLtNixZVYijMSDbWYi4oTAffbTSsbAwAA X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Dec 2017 00:32:33 -0000 --Rgf3q3z9SdmXC6oT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Dear FreeBSD Community, The deadline for the next FreeBSD Quarterly Status update is January 14, 2018, for work done in October through December. Status report submissions do not need to be very long. They may be about anything happening in the FreeBSD project and community, and provide a great way to inform FreeBSD users and developers about work that is underway and completed. Submission of reports is not restricted to committers; anyone doing anything interesting and FreeBSD related can -- and should -- write one! The preferred and easiest submission method is to use the XML generator [1] with the results emailed to the status report team at monthly@FreeBSD.org . (Do be sure, though, to save the form output and not the form itself! In particular, the Google Chrome "save as" function does not save the generated output for some reason.) There is also an XML template [2] that can be filled out manually and attached if preferred. For the expected content and style, please study our guidelines on how to write a good status report [3]. You can also review previous issues [4][5] for ideas on the style and format. We look forward to seeing your 2017Q4 reports! Thanks, Ben (on behalf of monthly@) [1] https://www.FreeBSD.org/cgi/monthly.cgi [2] https://www.FreeBSD.org/news/status/report-sample.xml [3] https://www.FreeBSD.org/news/status/howto.html [4] https://www.FreeBSD.org/news/status/report-2017-07-2017-09.html [5] https://www.FreeBSD.org/news/status/report-2017-04-2017-06.html --Rgf3q3z9SdmXC6oT Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQG3BAABCgAdFiEE2WGV4E2ARf9BYP0XKNmm82TrdRIFAlpBl14ACgkQKNmm82Tr dRLa5Awfb5Vk9nkQodZiZS9vWE+/mkfOEoT70yAhxCPlds+gzuny94jgLk4N7teL bQgojMiLG8XWge4aIlFVQkjtnCKzmJUO9Y5bxekCvLoJWDKwmCEVzM62PnQFYCi0 HoF/DP/9+bt3Dn3MX+Vya02+Dm/3NFQIXZlfelH9LSbfTfa7XrLF1ve0tQSYLf9H HXLJbNkVI4nB/FoTRWAerQkG9OHvZuyHD7XJAGIcpf1HlJUj8k3SZIDxczuhs2bx PHCkZvZ3oJzAVnqh5TMY6KrQI2gsgvLGM/Qyd8ZMg8lpO7rJ13NXlFElwrZnfSoH Q6uhg9mVbRm2STZGUbJT+lo61X5l83NOMAOOKDMrhdSanqZKUqpwN+nWYplgJ/5U h8VA3jkFz3ksK4lTH9xZT46hl3ibLAHcWkcRKEpYqMOUnkW7CoY4OFk3dEW/hlWC 4vS6+sFIMokqOOXy4aNsjZzC/lZ2Ru4yqUJU+rZFdEOrKtTFJdtfuI9IqCCngEE3 8/po3rEWFiMejQ== =jdpn -----END PGP SIGNATURE----- --Rgf3q3z9SdmXC6oT-- From owner-freebsd-hackers@freebsd.org Tue Dec 26 09:11:04 2017 Return-Path: Delivered-To: freebsd-hackers@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 99925EABD7C; Tue, 26 Dec 2017 09:11:04 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [78.47.246.247]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 2EE9B6B97B; Tue, 26 Dec 2017 09:11:03 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221] (may be forged)) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id vBQ9AouN058874 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 26 Dec 2017 10:10:51 +0100 (CET) (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: freebsd-stable@FreeBSD.org Received: from eg.sd.rdtc.ru (eugen@localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTP id vBQ9Ag3p048301; Tue, 26 Dec 2017 16:10:43 +0700 (+07) (envelope-from eugen@grosbein.net) To: FreeBSD Stable From: Eugene Grosbein Subject: idprio(1) broken X-Enigmail-Draft-Status: N1110 Cc: FreeBSD Hackers Message-ID: <5A421212.4040703@grosbein.net> Date: Tue, 26 Dec 2017 16:10:42 +0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=2.2 required=5.0 tests=BAYES_00, LOCAL_FROM, RDNS_NONE autolearn=no autolearn_force=no version=3.4.1 X-Spam-Report: * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 1.9 RDNS_NONE Delivered to internal network by a host with no rDNS * 2.6 LOCAL_FROM From my domains X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on hz.grosbein.net X-Spam-Level: ** X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Dec 2017 09:11:04 -0000 Hi! Is idprio(1) broken in stable/11? As root, start one bzip2 instance with idprio and one additional bzip2 intance per CPU core: # idprio 5 bzip2 -9 /dev/null & # n=$(sysctl -n kern.smp.cpus) # i=1; while [ $i -le $n ]; do bzip2 -9 /dev/null & i=$(($i+1)); done # top For dual core system, I see that idprio'd bzip2 takes all cycles of first core and two "normal" bzip2's share cycles of second core each taking ~50% of CPU time. It is expected that idprio'd bzip2 get no CPU time at all and each of "normal" bzip2's get ~100% of single CPU core for such setup. Eugene Grosbein From owner-freebsd-hackers@freebsd.org Tue Dec 26 09:18:32 2017 Return-Path: Delivered-To: freebsd-hackers@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 314F5EAC4C1; Tue, 26 Dec 2017 09:18:32 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [78.47.246.247]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id A9ECB6BF75; Tue, 26 Dec 2017 09:18:31 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221] (may be forged)) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id vBQ9IND2058935 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 26 Dec 2017 10:18:24 +0100 (CET) (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: freebsd-stable@FreeBSD.org Received: from eg.sd.rdtc.ru (eugen@localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTP id vBQ9IKLl050625; Tue, 26 Dec 2017 16:18:20 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: idprio(1) broken To: FreeBSD Stable References: <5A421212.4040703@grosbein.net> Cc: FreeBSD Hackers From: Eugene Grosbein Message-ID: <5A4213DC.20508@grosbein.net> Date: Tue, 26 Dec 2017 16:18:20 +0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <5A421212.4040703@grosbein.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=2.2 required=5.0 tests=BAYES_00, LOCAL_FROM, RDNS_NONE, T_DATE_IN_FUTURE_Q_PLUS autolearn=no autolearn_force=no version=3.4.1 X-Spam-Report: * 0.0 T_DATE_IN_FUTURE_Q_PLUS Date: is over 4 months after Received: date * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 1.9 RDNS_NONE Delivered to internal network by a host with no rDNS * 2.6 LOCAL_FROM From my domains X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on hz.grosbein.net X-Spam-Level: ** X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Dec 2017 09:18:32 -0000 On 26.12.2017 16:10, Eugene Grosbein wrote: > Is idprio(1) broken in stable/11? > > As root, start one bzip2 instance with idprio and one additional bzip2 intance per CPU core: > > # idprio 5 bzip2 -9 /dev/null & > # n=$(sysctl -n kern.smp.cpus) > # i=1; while [ $i -le $n ]; do bzip2 -9 /dev/null & i=$(($i+1)); done > # top > > For dual core system, I see that idprio'd bzip2 takes all cycles of first core > and two "normal" bzip2's share cycles of second core each taking ~50% of CPU time. > > It is expected that idprio'd bzip2 get no CPU time at all and each of "normal" bzip2's > get ~100% of single CPU core for such setup. This works as expected for stable/10. From owner-freebsd-hackers@freebsd.org Tue Dec 26 12:01:35 2017 Return-Path: Delivered-To: freebsd-hackers@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 87B8DE891D9; Tue, 26 Dec 2017 12:01:35 +0000 (UTC) (envelope-from agapon@gmail.com) Received: from mail-lf0-f54.google.com (mail-lf0-f54.google.com [209.85.215.54]) (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 D55BA722D0; Tue, 26 Dec 2017 12:01:34 +0000 (UTC) (envelope-from agapon@gmail.com) Received: by mail-lf0-f54.google.com with SMTP id f13so39419506lff.12; Tue, 26 Dec 2017 04:01:34 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=CrhIZ/Q9EvJosyG+gLCU2iiFg13+DyriWf3cYt1lSAg=; b=Mq0yQRR6JIz+nOtORXfk3qmdh3CsAesiaHcd5Zqr5Fpukq+NU/l0wI9l9n/6/jytWI 7zHtFLvu02NsNinP7P/Kckk9jVrrOIZht9dyRdu3UiHX8Oge4eYLkAHAuqUYrbjGlq3w mgI+8qM6fZOR7+39kaKLVaWcvoWXAME4SFIwn7ayfkXd4V/R3g00t9kjGm4zcBGiTjGG xQiUWkFJHTwysWnNUc9MBEbBvzPreL6WmZBy4MUbsv+HDqra2XTVum1avi4VwNZafFT0 75+QzIITv81DO/9dHPMfH9RReRoLyq7hGq2wIYv5JjzLllBrkTYpk/mDWPm0xM4WsPyA mzdg== X-Gm-Message-State: AKGB3mICn93Ms5qSVsBqYmudCOWFdzx52BJjmCSCVtIU0JEJsLg+iPU5 otnoQU2JUL2OlS11reU9xFrt92qM X-Google-Smtp-Source: ACJfBovQeQ7JCmsuO5TVessS2UqUSr/aJftKJz/yjXBFJo6HNscB4PwFbz3wlADAerhV7Rerbij9QA== X-Received: by 10.25.145.9 with SMTP id t9mr4179775lfd.88.1514288247340; Tue, 26 Dec 2017 03:37:27 -0800 (PST) Received: from [192.168.0.88] (east.meadow.volia.net. [93.72.151.96]) by smtp.googlemail.com with ESMTPSA id v207sm1860299lfa.3.2017.12.26.03.37.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 Dec 2017 03:37:26 -0800 (PST) Subject: Re: idprio(1) broken To: Eugene Grosbein , FreeBSD Stable Cc: FreeBSD Hackers References: <5A421212.4040703@grosbein.net> <5A4213DC.20508@grosbein.net> From: Andriy Gapon Message-ID: <92a254fb-8066-4930-e4ad-f4fedb0e84d0@FreeBSD.org> Date: Tue, 26 Dec 2017 13:37:25 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <5A4213DC.20508@grosbein.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Dec 2017 12:01:35 -0000 On 26/12/2017 11:18, Eugene Grosbein wrote: > On 26.12.2017 16:10, Eugene Grosbein wrote: > >> Is idprio(1) broken in stable/11? >> >> As root, start one bzip2 instance with idprio and one additional bzip2 intance per CPU core: >> >> # idprio 5 bzip2 -9 /dev/null & >> # n=$(sysctl -n kern.smp.cpus) >> # i=1; while [ $i -le $n ]; do bzip2 -9 /dev/null & i=$(($i+1)); done >> # top >> >> For dual core system, I see that idprio'd bzip2 takes all cycles of first core >> and two "normal" bzip2's share cycles of second core each taking ~50% of CPU time. >> >> It is expected that idprio'd bzip2 get no CPU time at all and each of "normal" bzip2's >> get ~100% of single CPU core for such setup. > > This works as expected for stable/10. Seems to work as expected on head as well. Tested on a 6-core physical system and a 2-core bhyve VM. # ps axwwl | fgrep bzip2 0 943 935 0 129 5 10564 2196 - RN 1 0:00.00 idprio 5 bzip2 -9 0 945 935 0 108 5 18332 9676 - RN 1 1:16.15 bzip2 -9 0 946 935 0 108 5 18332 9676 - RN 1 1:16.34 bzip2 -9 idprio isn't even able to exec bzip2. # ps axwwl | fgrep bzip2 0 28986 86816 0 129 5 18348 2324 - RN 17 0:00.02 bzip2 -9 0 28988 86816 0 106 5 18348 9680 - RN 17 1:27.25 bzip2 -9 0 28989 86816 0 106 5 18348 9680 - RN 17 1:27.86 bzip2 -9 0 28990 86816 0 108 5 18348 9680 - RN 17 1:35.50 bzip2 -9 0 28991 86816 0 106 5 18348 9680 - RN 17 1:27.00 bzip2 -9 0 28992 86816 0 106 5 18348 9680 - RN 17 1:25.83 bzip2 -9 0 28993 86816 0 106 5 18348 9680 - RN 17 1:26.76 bzip2 -9 -- Andriy Gapon From owner-freebsd-hackers@freebsd.org Tue Dec 26 12:41:31 2017 Return-Path: Delivered-To: freebsd-hackers@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 C71F9E8B9D4; Tue, 26 Dec 2017 12:41:31 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [78.47.246.247]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 59DA073D17; Tue, 26 Dec 2017 12:41:30 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221] (may be forged)) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id vBQCfMYO060437 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 26 Dec 2017 13:41:22 +0100 (CET) (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: avg@FreeBSD.org Received: from eg.sd.rdtc.ru (eugen@localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTP id vBQCfI47018041; Tue, 26 Dec 2017 19:41:18 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: idprio(1) broken To: Andriy Gapon , FreeBSD Stable References: <5A421212.4040703@grosbein.net> <5A4213DC.20508@grosbein.net> <92a254fb-8066-4930-e4ad-f4fedb0e84d0@FreeBSD.org> Cc: FreeBSD Hackers From: Eugene Grosbein Message-ID: <5A42436E.9060502@grosbein.net> Date: Tue, 26 Dec 2017 19:41:18 +0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <92a254fb-8066-4930-e4ad-f4fedb0e84d0@FreeBSD.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=2.2 required=5.0 tests=BAYES_00, LOCAL_FROM, RDNS_NONE, T_DATE_IN_FUTURE_Q_PLUS autolearn=no autolearn_force=no version=3.4.1 X-Spam-Report: * 0.0 T_DATE_IN_FUTURE_Q_PLUS Date: is over 4 months after Received: date * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 1.9 RDNS_NONE Delivered to internal network by a host with no rDNS * 2.6 LOCAL_FROM From my domains X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on hz.grosbein.net X-Spam-Level: ** X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Dec 2017 12:41:31 -0000 On 26.12.2017 18:37, Andriy Gapon wrote: >>> Is idprio(1) broken in stable/11? >>> >>> As root, start one bzip2 instance with idprio and one additional bzip2 intance per CPU core: >>> >>> # idprio 5 bzip2 -9 /dev/null & >>> # n=$(sysctl -n kern.smp.cpus) >>> # i=1; while [ $i -le $n ]; do bzip2 -9 /dev/null & i=$(($i+1)); done >>> # top >>> >>> For dual core system, I see that idprio'd bzip2 takes all cycles of first core >>> and two "normal" bzip2's share cycles of second core each taking ~50% of CPU time. >>> >>> It is expected that idprio'd bzip2 get no CPU time at all and each of "normal" bzip2's >>> get ~100% of single CPU core for such setup. >> >> This works as expected for stable/10. > > Seems to work as expected on head as well. I have a report that head r323607 has the problem and head r326729 has not. I can't check it myself as I have do not run head yet. From owner-freebsd-hackers@freebsd.org Tue Dec 26 17:33:23 2017 Return-Path: Delivered-To: freebsd-hackers@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 DEF1DEA4574 for ; Tue, 26 Dec 2017 17:33:23 +0000 (UTC) (envelope-from debdrup@gmail.com) 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 BB39D7FA38 for ; Tue, 26 Dec 2017 17:33:23 +0000 (UTC) (envelope-from debdrup@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id BA7ACEA4573; Tue, 26 Dec 2017 17:33:23 +0000 (UTC) Delivered-To: hackers@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 B9E12EA4572 for ; Tue, 26 Dec 2017 17:33:23 +0000 (UTC) (envelope-from debdrup@gmail.com) Received: from mail-pg0-x22d.google.com (mail-pg0-x22d.google.com [IPv6:2607:f8b0:400e:c05::22d]) (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 8E6707FA37 for ; Tue, 26 Dec 2017 17:33:23 +0000 (UTC) (envelope-from debdrup@gmail.com) Received: by mail-pg0-x22d.google.com with SMTP id i5so1971467pgq.11 for ; Tue, 26 Dec 2017 09:33:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=TSI+G1Dyjmuuou831OZecg/6S3DcGK9YJaIb3FaaEnA=; b=GqU59IvqAO6XFlXIs2l7s/KV0Uztcuvaij30yeZV1WOy6jhzAcb9MFTdKoU1IaMu1N CNjcPwrv9nwe+hKY06LjXzO7RqbPb+DH9tU3rVj72yDCYP9HaujoyFKIAZXCHK8WGCTN AQP18Ta3Q0u3Mgtzc5Sr7D3D1OPiN36Qhl8KsLYqXxRza3QSrZ+BQCQe3Nuf25Tbb4Qj ZdgV7rtKTCzF6BUeChmMIIoUjnReNr6CwQ/QCWJH6rplpl5crRDGr//27mbTU0ADd++F Zsk0YF/Y9PT7fF2R4orEen4zvkr7CqbyrRpN2YgbZQ6uGTqrADTqblZwlT3paU5WaEYy ZlEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=TSI+G1Dyjmuuou831OZecg/6S3DcGK9YJaIb3FaaEnA=; b=XU5KKLvOmduZmuPM9O8FdkBzbIrk4O/7y/d5W7P+sM+MiTpBGNnJcTUOIZX19vnkaH Fxw8CdnNeBYMFE/nqmfukAKoG8y8rNr4JYZDFMgKYjKCXlOfFlqXU1+g4UXrd9tBHUsI XvNRINajKmpZS77ikqmv2VDEjg0O46DYNaK6zg62SacwRT+4EPzvCCifZK5e42JVFisv SCpo30nmFqZP8ttMehmwm1eLo3SDM1FdeDrpdGX89WVcoeWjgncs0V4K//nEGKRv9iZb /DZ1IC9HaqXVQ+BgFb7DlJ1Me+EX4lqFnn8N4YsmMP/PPU+8wXZ5NsdTo4ZQJSsJoE7U G+YQ== X-Gm-Message-State: AKGB3mIQ0O94ixPDhCj2JjJ9aDWl3Cde8r5punH2hU9ieIMvqiEUOwn+ 2jgoI9zLzJM8bCYPcfF3YMk/jXZj7JTravyILlmueA== X-Google-Smtp-Source: ACJfBosPOjLxawBlaqWDo//jA0xKNm1irPnq76bHOySzY7bHJOBTHEOdKbdObnTdC1MG2Lw+C+HCHVe7HoguJP8+bBU= X-Received: by 10.98.181.25 with SMTP id y25mr11520302pfe.206.1514309602945; Tue, 26 Dec 2017 09:33:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.247.140 with HTTP; Tue, 26 Dec 2017 09:33:22 -0800 (PST) From: "D. Ebdrup" Date: Tue, 26 Dec 2017 18:33:22 +0100 Message-ID: Subject: RE: OOM problem? To: hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Dec 2017 17:33:24 -0000 In looking through sys/vm/vm_pageout.c to find out whether a problem on Illumos relating to process swapping (bug here: https://www.illumos.org/issues/6583) also has any relevance to FreeBSD (because CarlosN26157061 on Twitter mentioned it), I noticed that the code has been relatively untouched since its import from 4.xBSD sources, and got to thinking of this thread and was wondering if it's somehow related, and whether FreeBSD should also get rid of process swapping. If not, please excuse my interruption in this thread. >Hi hackers, >I've been playing around on a box that Netflix loaned me, I'm thinking >about novel ways to deal with NUMA issues. >[snip] >Thanks, >--lm Daniel Ebdrup aka. D. Ebdrup. From owner-freebsd-hackers@freebsd.org Tue Dec 26 23:01:13 2017 Return-Path: Delivered-To: freebsd-hackers@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 7953EE88C5A for ; Tue, 26 Dec 2017 23:01:13 +0000 (UTC) (envelope-from bsd-lists@BSDforge.com) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 664286B56C for ; Tue, 26 Dec 2017 23:01:13 +0000 (UTC) (envelope-from bsd-lists@BSDforge.com) Received: by mailman.ysv.freebsd.org (Postfix) id 65B31E88C58; Tue, 26 Dec 2017 23:01:13 +0000 (UTC) Delivered-To: hackers@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 65652E88C57 for ; Tue, 26 Dec 2017 23:01:13 +0000 (UTC) (envelope-from bsd-lists@BSDforge.com) Received: from udns.ultimatedns.net (static-24-113-41-81.wavecable.com [24.113.41.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3CA986B56A for ; Tue, 26 Dec 2017 23:01:12 +0000 (UTC) (envelope-from bsd-lists@BSDforge.com) Received: from udns.ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id vBQN3Qdr007660; Tue, 26 Dec 2017 15:03:32 -0800 (PST) (envelope-from bsd-lists@BSDforge.com) X-Mailer: UDNSMS MIME-Version: 1.0 Cc: "hackers@freebsd.org>" In-Reply-To: From: "Chris H" Reply-To: bsd-lists@BSDforge.com To: "Warner Losh" Subject: Re: devmatch(8) committed .... Date: Tue, 26 Dec 2017 15:03:32 -0800 Message-Id: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Dec 2017 23:01:13 -0000 On Mon, 25 Dec 2017 11:57:10 -0700 "Warner Losh" said > I've committed devmatch(8) to the tree in r327176=2E It's a building block > for automating the loading of modules=2E While we can load modules today by > adding FOO_load=3DYES to loader=2Econf, there's no easy way to load only th= e > modules you need based on the hardware you have in the system=2E devmatch(8= ) > provides the base framework to allow one to do that=2E It does this my > looking at the PNP tables recorded in /boot/kernel/linker=2Ehints=2E I've been *going* to something like this for a long time=2E Thank you!!! >=20 > The version I've committed doesn't have the devd nor the rc=2Ed integration= =2E > I've committed it for people to play with and give me feedback while thos= e > parts are finalized (and while other bugs are fixed)=2E I don't intend to > commit them until the kinks are worked out=2E >=20 > Some notes: >=20 > (1) You'll need a newly built kernel=2E Older kernels have minor bugs that > allowed the terminating sentinel to be included in linker hints=2E All know= n > oens, at least for amd64, have been fixed=2E > (2) Lots and lots of drivers need to have their plug and play tables > decorated=2E This is where I need people's help=2E I'll be writing up somethi= ng > for those that want to help=2E ISAPNP, PC Card and USB drivers already have > this data=2E A few PCI drivers have it, and almost no ACPI drivers=2E The dat= a > is generally there, just not properly decorated for devmatch(8) and > kldxref(8) to do their thing=2E > (3) There's an issue with the USB pnp data=2E It's too long for the current > devinfo(3) interfaces=2E I have fixes in the works to correct this=2E I could > just bump the limits, but I want to do something more general and long te= rm=2E > (4) The end game for this is a GENERIC with most of the drivers removed > that loads drivers automatically=2E Bootable storage drivers will have to > remain for now until the loader can make use of this code=2EThis is why the > warning about hinted ISA devices went into the tree this week=2E > (5) modules will print more than once=2E also the if_em/if_igb driver is a > hard link so both of those will always print=2E >=20 > Please send me your feedback=2E Happy Holidays! Right back at you, and thanks again! --Chris >=20 > Warner From owner-freebsd-hackers@freebsd.org Wed Dec 27 03:19:23 2017 Return-Path: Delivered-To: freebsd-hackers@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 B3050E9DE2C for ; Wed, 27 Dec 2017 03:19:23 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-yb0-x22b.google.com (mail-yb0-x22b.google.com [IPv6:2607:f8b0:4002:c09::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 6ED8D744A8 for ; Wed, 27 Dec 2017 03:19:23 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: by mail-yb0-x22b.google.com with SMTP id q3so9434761ybg.9 for ; Tue, 26 Dec 2017 19:19:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:from:date:message-id:subject:to; bh=su4SL6mkfLil2oOqn9k5Ld9TyAHT0FHgJihwQ9n8gPk=; b=astq74AqQIioubR1v5Sj2GIadmi6dtPkAxHQk5EuCuITT77WXZQ3cqcOd+vvd8rPFF aDNQab7nucQb1mV5mRrieYPx7dJ/2zSrD31z1kCn4e7w1a9GV75hrRLiOTwNbPEfRKq5 8h/VdVgLmIbvJegZVzuW86l3ERZiuyguL+doQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=su4SL6mkfLil2oOqn9k5Ld9TyAHT0FHgJihwQ9n8gPk=; b=MUkSUZkx/iNS51/YI94+sDO7SPXjk4P7kk99tGW5hpwWdjrYTtykwWs8g00h/wOrFa bH52tLCBnTELyA7hHC8V60wDqmVMgU1CLtyn4GaCE5bWrYlGaVpxQWjBGBs8Idq8enxI NNAqN4u+9qpTZKj7677U3G/HMbWVN4Nawnobxa9ZXAkFv+SKxDbX5Q8QrTtiY1jupTmX 4GAx7G3ac+9jNsSooTuj3Q9OmAWXpykSKuCS4CZTLaa3Mj1QHv1ARUCfXq2gB92DGULE jdbHerk6vr+FJKqL8PQTiezJ3zprZz/RsAUE64hQCYyZLIdaR2LnXEq8xh76L09ew3F3 bx3g== X-Gm-Message-State: AKGB3mL7Xqgq4xtkSYhS/1PhFHyrtciyfnRbZt11bFcvaCPsqpXKJW6z 0iMoBeekFln/C0TCImPx0HXCt6h2iPfb6FQivgzzZ4J4 X-Google-Smtp-Source: ACJfBounr592b+kpc8mx+rXV5IBzTF8nrRheDrqqRzHiHwvsxlmgV7d72LLW0S+sw2ZXX3OaoemCK67prLNVfWaCMo8= X-Received: by 10.37.73.194 with SMTP id w185mr2235957yba.170.1514344762233; Tue, 26 Dec 2017 19:19:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.217.21 with HTTP; Tue, 26 Dec 2017 19:18:51 -0800 (PST) From: Eitan Adler Date: Tue, 26 Dec 2017 19:18:51 -0800 Message-ID: Subject: Parsing a comment in stdlib.h To: FreeBSD Hackers , benno@freebsd.org, gwollman@freebsd.org Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Dec 2017 03:19:23 -0000 Hi all, I'm trying to understand a visibility comment in stdlib.h. Is the following change technically correct? Can it be made more clear? Index: include/stdlib.h =================================================================== --- include/stdlib.h (revision 327228) +++ include/stdlib.h (working copy) @@ -120,8 +120,10 @@ int wctomb(char *, wchar_t); size_t wcstombs(char * __restrict, const wchar_t * __restrict, size_t); /* - * Functions added in C99 which we make conditionally available in the - * BSD^C89 namespace if the compiler supports `long long'. + * Functions added in C99 which we make available if + * - its C99 + * - BSD visible and not C89 + * - its C++ * The #if test is more complicated than it ought to be because * __BSD_VISIBLE implies __ISO_C_VISIBLE == 1999 *even if* `long long' * is not supported in the compilation environment (which therefore means -- Eitan Adler From owner-freebsd-hackers@freebsd.org Wed Dec 27 04:05:42 2017 Return-Path: Delivered-To: freebsd-hackers@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 12061EA06CA for ; Wed, 27 Dec 2017 04:05:42 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-lf0-x233.google.com (mail-lf0-x233.google.com [IPv6:2a00:1450:4010:c07::233]) (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 793D776219; Wed, 27 Dec 2017 04:05:41 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-lf0-x233.google.com with SMTP id w196so23203497lff.5; Tue, 26 Dec 2017 20:05:41 -0800 (PST) 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=xfHCS5vRCOYX2qWbcWD/+Cc9eXbTe6qj2A5xAgF+9bk=; b=MkS40a0oA66gVsdK5LMQmgZNxIKmy9mHOEMFN41yIStxwPbqut8pMEsrODhiwZYRHT Jefxk6b9659TPcyT3/ZpTdiRnrveSk7A28tI+M3YZlFRGXcKUeQbFIH8qTkZXQ0Iw2KQ mGkQ/Y6cuJrXa9rQA/JgTrcenRx2Z6qle3qB8GDejx7RvruuUHvNma8UVhNOFqmWd9q+ KeYESsLukWWzMCo9dQmbG9GuQOn/M33eX2Dtbv3gFYctDwDXOwKEH3hQVWREVi40Z4QY tDe4zuVzJiv4gpxOGa4gvJPYPS34AHem4qX/YBymdTypWoQoA6ONsqkfsXguiNcMJ/6Q 7bEQ== 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=xfHCS5vRCOYX2qWbcWD/+Cc9eXbTe6qj2A5xAgF+9bk=; b=Ki+RhugxYKOG1Ot6SPUA28CRHKlvc3BFVj5RgIIokHX9YRJ6hwLTv8h+iXyMaCxUN1 T3rVRYq7JbKC2fsDWxpXFqx5EWF5CmWHaWfRvFr89QTGFCo5Yjdq1pM9RZMx9/WJ4ld0 oQM0t9ZLS1l3pwLgqNY8lrNg5r1JJ2dQjYJC5eI9ELjmFmWhWc1bLToydwlBll977Nbm YFcmS/PJ3PaAUVMzaONvZ9oSVa4kSzEoLRrW1XPPocSe71K74Chagx5oH6jK7i2FU3d5 2ag+yEpRM9kHRsP24uIR8klDYUezxgQ+DsS9NLXtt0fR7FJWd0ZTj9QRaj6OqFJch0d/ ecZA== X-Gm-Message-State: AKGB3mJqfwC714jKNr8Ijv4ejsrUeukObwoPbR2jNkA2xGSIGe2fLFvz gsQsjj6iNQCj/JtivpyEzjLsOBjeiN9V0/Nur2s= X-Google-Smtp-Source: ACJfBosSl4/6T2/TZvNaZmcvrpX+FUZrTYpLG7c/cEsggnwkm0VYjbaReHdz8WqGE/cEkB2i9+xebfx4F45aET0WAUk= X-Received: by 10.46.88.77 with SMTP id x13mr15471801ljd.80.1514347538766; Tue, 26 Dec 2017 20:05:38 -0800 (PST) MIME-Version: 1.0 Sender: asomers@gmail.com Received: by 10.179.76.19 with HTTP; Tue, 26 Dec 2017 20:05:38 -0800 (PST) In-Reply-To: References: From: Alan Somers Date: Tue, 26 Dec 2017 21:05:38 -0700 X-Google-Sender-Auth: D_1a_c86V3QrjsDWucJboy31tFs Message-ID: Subject: Re: Parsing a comment in stdlib.h To: Eitan Adler Cc: FreeBSD Hackers , Benno Rice , gwollman@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Dec 2017 04:05:42 -0000 I would say that your proposed change makes it less clear. For one thing, it's not clear whether those three bullet points are meant to be ANDed or ORed. For another, I'm not sure why you removed the part about "long long". Finally, s/its/it's/. Frankly, I think the comment can just be shortened to "C99 functions". GCC and Clang both support "long long". Are there any external compilers that don't? On Tue, Dec 26, 2017 at 8:18 PM, Eitan Adler wrote: > Hi all, > > I'm trying to understand a visibility comment in stdlib.h. Is the > following change technically correct? > Can it be made more clear? > > Index: include/stdlib.h > =================================================================== > --- include/stdlib.h (revision 327228) > +++ include/stdlib.h (working copy) > @@ -120,8 +120,10 @@ int wctomb(char *, wchar_t); > size_t wcstombs(char * __restrict, const wchar_t * __restrict, size_t); > > /* > - * Functions added in C99 which we make conditionally available in the > - * BSD^C89 namespace if the compiler supports `long long'. > + * Functions added in C99 which we make available if > + * - its C99 > + * - BSD visible and not C89 > + * - its C++ > * The #if test is more complicated than it ought to be because > * __BSD_VISIBLE implies __ISO_C_VISIBLE == 1999 *even if* `long long' > * is not supported in the compilation environment (which therefore means > > > -- > Eitan Adler > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@freebsd.org Wed Dec 27 06:35:43 2017 Return-Path: Delivered-To: freebsd-hackers@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 B24FEEA6D8C for ; Wed, 27 Dec 2017 06:35:43 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::22d]) (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 748717A01C for ; Wed, 27 Dec 2017 06:35:43 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x22d.google.com with SMTP id o130so26963466itg.0 for ; Tue, 26 Dec 2017 22:35:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=ZDGUsUaW7+ALSUdU+kprYuCJHWKDTRmmggbhYhM/Ss0=; b=1mDV/t2iKuHNNxejIZUaf+z8zcf1UANKqXVWeQobbVrZAWnkkV5vSBBRH64a5FVy9e aU2t20ZXPZJzxVJMQ/JbVybhqnapKSkkwvs+YR8mh9agkl1FN85FBsF6SZS+tZ93hd1a 6HjpvPDmqmHE4EbvJ0IWaf87IYgn5M5Zi+7nJo903YDPTudGc7Y1t6ix9pVYbZA2680j /4WxnLCgk8CgAi5FuqilNxYZsKkTh2RiNOhtN088fKSTvk/6WtO4cbnnWp2b+ikDrHlj GuAp2GMeFx7XsS+qaXSI+pC0j5zGtRMHc4p+gjf/aB8GuJsK8TVUysCDD+heU2T6tUAE 3Byw== 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=ZDGUsUaW7+ALSUdU+kprYuCJHWKDTRmmggbhYhM/Ss0=; b=syNtj2OGYc3s+Nl2EmrAlSX47t411eAnrVmFrZSBHqwaJz7sBRyP0oSbOh3p2Ac66j BieSYx9sCN6cELdAPtkddf7KsWhFSTkJx4RcJihd2kwIr3Z2ufujPLsDa+YplENxGriv In9tF2cuOG7sORwHeWnv41AdrGBce9aVHRPj/mRLbSfYreUonjrXJNnR+nFNMNLQkgAJ T+MyTiYYhcrRKrwvkParSMJ8B2Hk9Wk6ZlSZzQa+QxtLlP6uFHciDAjBDhhzFNrqfLKm LPROkuh4gOXfb08KlNirVZ3rTTXMObdnc3zJHczl6WS8hyPYhsHHCLgDF5tanxnviUxm xSNA== X-Gm-Message-State: AKGB3mJFvTVeRvvHpXCqF6nvceRhiUcowkM3X8+8haMK0VCpYAOeKj5n q5hRwNSj5YcGT/mli/8d4ourTmfbq7s9fxIMfSiPig== X-Google-Smtp-Source: ACJfBosMOXTDpIb7LKStwUFGR+X24eRJeYtzFtajlBlwvagyLWQ7MIy0ahrtbyLGcMG9tqg6ykg0VkQd9+SId+zdaeA= X-Received: by 10.36.131.200 with SMTP id d191mr35501702ite.97.1514356542608; Tue, 26 Dec 2017 22:35:42 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.108.204 with HTTP; Tue, 26 Dec 2017 22:35:41 -0800 (PST) X-Originating-IP: [2603:300b:6:5100:1052:acc7:f9de:2b6d] In-Reply-To: References: From: Warner Losh Date: Tue, 26 Dec 2017 23:35:41 -0700 X-Google-Sender-Auth: b9RVjVil_yev473JDZ68BUIKqxE Message-ID: Subject: Re: Parsing a comment in stdlib.h To: Alan Somers Cc: Eitan Adler , FreeBSD Hackers , gwollman@freebsd.org, Benno Rice Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Dec 2017 06:35:43 -0000 I find the proposed comment less clear. In fact, I'd go so far as to say its brevity makes it misleadingly wrong. It turns out that __LONG_LONG_SUPPORTED is switchable via compiler flags (in both gcc and clang), hence the need to have these #ifdefs in a standard file. gcc -ansi accepts long long with a warning, but does define __STRICT_ANSI__ so you can create warning free code. All of this happens far away from stdlib.h in sys/cdefs.h: #if (defined(__INTEL_COMPILER) || (defined(__GNUC__) && __GNUC__ >= 2)) && !defined(__STRICT_ANSI__) || __STDC_VERSION__ >= 199901 #define __LONG_LONG_SUPPORTED #endif clang defines __GNUC__ so that __LONG_LONG_SUPPORTED is identical to gcc in the brief testing I just did. One should really read "if the compiler supports 'long long'" as "if the compiler is invoked in a mode that supports long long without generating warnings" It's removal critically changes the meaning here, fatally so I'm afraid. The new text is of absolutely no help because in c89 mode, long long is supported and __LONG_LONG_SUPPORTED is defined. All this nuance is lost, and it's more than mere quibbles. I'd be tempted to leave it along because a full explanation would be quite verbose. Warner On Tue, Dec 26, 2017 at 9:05 PM, Alan Somers wrote: > I would say that your proposed change makes it less clear. For one thing, > it's not clear whether those three bullet points are meant to be ANDed or > ORed. For another, I'm not sure why you removed the part about "long > long". Finally, s/its/it's/. Frankly, I think the comment can just be > shortened to "C99 functions". GCC and Clang both support "long long". Are > there any external compilers that don't? > > On Tue, Dec 26, 2017 at 8:18 PM, Eitan Adler wrote: > > > Hi all, > > > > I'm trying to understand a visibility comment in stdlib.h. Is the > > following change technically correct? > > Can it be made more clear? > > > > Index: include/stdlib.h > > =================================================================== > > --- include/stdlib.h (revision 327228) > > +++ include/stdlib.h (working copy) > > @@ -120,8 +120,10 @@ int wctomb(char *, wchar_t); > > size_t wcstombs(char * __restrict, const wchar_t * __restrict, size_t); > > > > /* > > - * Functions added in C99 which we make conditionally available in the > > - * BSD^C89 namespace if the compiler supports `long long'. > > + * Functions added in C99 which we make available if > > + * - its C99 > > + * - BSD visible and not C89 > > + * - its C++ > > * The #if test is more complicated than it ought to be because > > * __BSD_VISIBLE implies __ISO_C_VISIBLE == 1999 *even if* `long long' > > * is not supported in the compilation environment (which therefore > means > > > > > > -- > > Eitan Adler > > _______________________________________________ > > freebsd-hackers@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@ > freebsd.org" > > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@freebsd.org Wed Dec 27 10:50:36 2017 Return-Path: Delivered-To: freebsd-hackers@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 A1524E84A42; Wed, 27 Dec 2017 10:50:36 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [78.47.246.247]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 2F49E1446; Wed, 27 Dec 2017 10:50:35 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221] (may be forged)) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id vBRAoLre070082 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 27 Dec 2017 11:50:22 +0100 (CET) (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: avg@FreeBSD.org Received: from eg.sd.rdtc.ru (eugen@localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTP id vBRAoDWO010683; Wed, 27 Dec 2017 17:50:13 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: idprio(1) broken To: Andriy Gapon , FreeBSD Stable References: <5A421212.4040703@grosbein.net> <5A4213DC.20508@grosbein.net> <92a254fb-8066-4930-e4ad-f4fedb0e84d0@FreeBSD.org> Cc: FreeBSD Hackers From: Eugene Grosbein Message-ID: <5A437AE5.4080104@grosbein.net> Date: Wed, 27 Dec 2017 17:50:13 +0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <92a254fb-8066-4930-e4ad-f4fedb0e84d0@FreeBSD.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=2.2 required=5.0 tests=BAYES_00, LOCAL_FROM, RDNS_NONE, T_DATE_IN_FUTURE_Q_PLUS autolearn=no autolearn_force=no version=3.4.1 X-Spam-Report: * 0.0 T_DATE_IN_FUTURE_Q_PLUS Date: is over 4 months after Received: date * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 1.9 RDNS_NONE Delivered to internal network by a host with no rDNS * 2.6 LOCAL_FROM From my domains X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on hz.grosbein.net X-Spam-Level: ** X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Dec 2017 10:50:36 -0000 On 26.12.2017 18:37, Andriy Gapon wrote: >>> It is expected that idprio'd bzip2 get no CPU time at all and each of "normal" bzip2's >>> get ~100% of single CPU core for such setup. >> >> This works as expected for stable/10. > > Seems to work as expected on head as well. I've updated my old stable/11 to recent stable/11 r327192 and problem's gone. Sorry for noise. From owner-freebsd-hackers@freebsd.org Wed Dec 27 16:25:15 2017 Return-Path: Delivered-To: freebsd-hackers@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 E161EE9F6CF; Wed, 27 Dec 2017 16:25:15 +0000 (UTC) (envelope-from aryeh.friedman@gmail.com) Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::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 B661D6BFDF; Wed, 27 Dec 2017 16:25:15 +0000 (UTC) (envelope-from aryeh.friedman@gmail.com) Received: by mail-it0-x22c.google.com with SMTP id p139so25644990itb.1; Wed, 27 Dec 2017 08:25:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=GFKo6/7hsbnfTl6MipDjGxvqlfEc64cjVaVn8Sm3jIQ=; b=AHM6enSykesfvFjO3daWAbQ8MJzvv2tUk+kegTBKh8akW9agjtHiYjdXeTu8rFNaVM /ACri89XH7k6ywX9AHH5Yo5/qu7/QHdxG3NoDQ17aNz0J8YoveIP/VrQ8sQ7u4uA8uLi +ACnXLMWdD0tT8DArzuXfPh11D8o+hSo+OkUoevpYqpbvS4ztj5y1c3yK1gderg2gIo+ hNopkyDQVc1r5cS99U9MOv9v0h3dDt9yK5DQAt5/ilwRrOAcioFtd4m8WROpyOAePXCL +Hwo7J4Yh6hkhtyq4U9eIFkxp568FC5bdq+Gfxsz3AlyjKwW2xvj8TBjavtBE9D+ZLdv A19g== 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; bh=GFKo6/7hsbnfTl6MipDjGxvqlfEc64cjVaVn8Sm3jIQ=; b=k3dx3HF5867JEJaBMBiXi4A+dPDaB/m4OscO+tFDVVExwemOgXIUoagnxV3e10ILFd PkQcvaKOX50lTmxOfE3bqdqzSOPAIKUC/q39d3lGS0wyk8OXt1jWDtDvIFF0UmkqJ8s6 5fGQzZUqV+VqObtgIl48by4KaJAaGJQig2G99xrmSrtWTozf91Hq9OtF1ipoRru7RpAr ht3sKv+nFeUmrcPu+BcHFpTeDZDqJwInitCq3n6qHzgjIZOclAZNnS3G3O6ycCienM8B ikq+8qqKwr2OEpl19Xu8qihhDFYgBATmqkDneT4oBll7B0kzv/00nFQFy+GQT0xTtVUT njIw== X-Gm-Message-State: AKGB3mJDnUgqxF4SQYdK5Iwvs3sN8FZ6lXpaMLtzIkPXt3YZAemaxkqE g1Pex2RT3K4mUf8joeZCMgwyq6s1RibtWTasAwI= X-Google-Smtp-Source: ACJfBot5Ki+gPGcrrhKjQQUz3BadxL76nC2sV7LJsydaW4tLamagDKkc6D5hjqalLdsyccV8R9fyznBhzQgbhGJb7d0= X-Received: by 10.36.129.212 with SMTP id q203mr40128866itd.152.1514391914949; Wed, 27 Dec 2017 08:25:14 -0800 (PST) MIME-Version: 1.0 Received: by 10.36.105.3 with HTTP; Wed, 27 Dec 2017 08:25:14 -0800 (PST) In-Reply-To: References: From: Aryeh Friedman Date: Wed, 27 Dec 2017 11:25:14 -0500 Message-ID: Subject: Re: Running dual boot windows inside of bhyve To: Joe Nosay Cc: "freebsd-virtualization@freebsd.org" , FreeBSD Mailing List , FreeBSD Mailing List Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Dec 2017 16:25:16 -0000 On Wed, Dec 27, 2017 at 11:17 AM, Joe Nosay wrote: > I'm curious as to why you would choose a lesser reliable system as the > guest. > Since I have several other VM's also running on it (they are where I do the torture testing of a webapp I maintain as well as browser compatibility [the reason for win 7/IE 11.0 is the client's largest customer uses that and *REFUSES* to upgrade/switch {doctors are even more stubborn then programmers} to a better/newer browser/os). Thus I often need to run two VM's at once on it (one is a copy of FBSD that can repeately be blown up in testing and the other is a copy of the OS we are having browser/client issues with at the moment). > The first thing you need to do is copy the partition to another drive. > Impractical since all bays are used. > On Mon, Dec 25, 2017 at 7:12 PM, Aryeh Friedman > wrote: > >> Cross posted to virtualization@, hackers@ and questions. >> >> I have a dual boot machine (windows 7 64 bit and fbsd 11.1-RELEASE >> [amd64]) >> and want to run the windows partition as a vm in bhyve how would I go >> about >> this. Bonus if the process is standalone scriptable so I can add it as a >> feature of PetiteCloud. >> >> -- >> Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org >> _______________________________________________ >> freebsd-hackers@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org >> " >> > > -- Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org From owner-freebsd-hackers@freebsd.org Wed Dec 27 17:15:16 2017 Return-Path: Delivered-To: freebsd-hackers@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 2DD12EA2015; Wed, 27 Dec 2017 17:15:16 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::229]) (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 BCD0D6DA10; Wed, 27 Dec 2017 17:15:15 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-lf0-x229.google.com with SMTP id o26so28709034lfc.10; Wed, 27 Dec 2017 09:15:15 -0800 (PST) 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=zy3Kwhdy74Tl5mXUkiB0n6nYdDWjbRF1ZlxU33xj1Do=; b=u0/tZeSpyxyxlBDWJExJoAJt+pLNRKO3p3cQDE9RtRW7alHYx5MAd64r6whkoFl7Gt kO9mFsNVp1trvfyr7X6a5uundEfRGruwyM8I3qnmZsAS+q7kyAo+T8W+8XTHG2M3YfbA FTZOZKxMKQDnmVfyTmIOUu2fQ6447V3KjFbfW1Y3EzzILpXyeucGQ/7UhCB7/jUcl6pY gxF7h/pL9PEq8xzL6wC9FzZvbgdZSnd9TG1g3uz2TVwvfrqcxClLc1l44uNSHaNiP8gW X0H640P+CX9ub2kMazg2n7G6ydW7N9zYp6xKbKFMyOBs7V8d5OdV+TpIQNb52PmFMjNe WFDQ== 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=zy3Kwhdy74Tl5mXUkiB0n6nYdDWjbRF1ZlxU33xj1Do=; b=NNmAUBAfJdwHphYKyociM8l82Jhx1M6fyoLFcrGbbkgGGmS9oX4KUfkTGyjdGY+7Ea sFjPr9zkQnPfG7ZuZ9aQJ9crLlXsKLtIDRioTgJnZxs55wSdzpfxy02cip4HCHOuI1yX PLTF4yfZi3SON8QE+F2UUGkGxPEoJ0skrqVsFWRYcdlyUdlw/oL81Zy0mn24/bJDobz9 hoQ00QAgS1l1Wv5yNPJ+sTOVURZfFxfUl7JCki3QJ2bIuBLvEF+yr2C82XlQrrJwdJgQ QthCAy/9+boMXB/Ucl9jpI1e8rbJhXDqUyHzOcFa7plYTs09QK3FR74O+UXpCuXgMee6 /RjQ== X-Gm-Message-State: AKGB3mIirmkPmtMZP9W4yytKV6LR3NILgkfY14OpUw/G3fRJtQkZXrFw JGzl2A4bWynhquIhOJgDTqsnK+Wa0G9+iVUujSc= X-Google-Smtp-Source: ACJfBotZ68mcEnlPLJXwFgGbtcKJZJBcpDcthxvMSrWlO9V+WW42wQzpPclBWRAZ7Nt9DdmP19VbsxDi108Q3DthZNU= X-Received: by 10.25.151.211 with SMTP id z202mr1769523lfd.51.1514394913713; Wed, 27 Dec 2017 09:15:13 -0800 (PST) MIME-Version: 1.0 Sender: asomers@gmail.com Received: by 10.179.76.19 with HTTP; Wed, 27 Dec 2017 09:15:12 -0800 (PST) In-Reply-To: References: From: Alan Somers Date: Wed, 27 Dec 2017 10:15:12 -0700 X-Google-Sender-Auth: ULpyuG8OLoj6lkiBlf2ao30p5Ps Message-ID: Subject: Re: Running dual boot windows inside of bhyve To: Aryeh Friedman Cc: "freebsd-virtualization@freebsd.org" , FreeBSD Mailing List , FreeBSD Mailing List Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Dec 2017 17:15:16 -0000 On Mon, Dec 25, 2017 at 5:12 PM, Aryeh Friedman wrote: > Cross posted to virtualization@, hackers@ and questions. > > I have a dual boot machine (windows 7 64 bit and fbsd 11.1-RELEASE [amd64]) > and want to run the windows partition as a vm in bhyve how would I go about > this. Bonus if the process is standalone scriptable so I can add it as a > feature of PetiteCloud. > > I fear that you may be out of luck. Windows deliberately frustrates this use case by profiling its hardware at installation time and at every boot thereafter. If the hardware changes too much, then Windows demands a new license fee. Moving from physical hardware to a VM would probably trip every one of its alarms. For this reason, I would recommend using a separate instance for your VM. However, if you do use a shared instance, then make sure that your PC is booting in UEFI mode. BHyve can only boot Windows in that mode. If you do that, then BHyve will probably be able to boot it just fine. -Alan From owner-freebsd-hackers@freebsd.org Wed Dec 27 17:37:27 2017 Return-Path: Delivered-To: freebsd-hackers@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 EB8A4EA3310; Wed, 27 Dec 2017 17:37:27 +0000 (UTC) (envelope-from rebecca@bluestop.org) Received: from muon.bluestop.org (muon.bluestop.org [IPv6:2605:7700:0:8:1:0:4a32:3323]) (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 CB97C6E843; Wed, 27 Dec 2017 17:37:27 +0000 (UTC) (envelope-from rebecca@bluestop.org) Received: from muon.bluestop.org (localhost [127.0.0.1]) by muon.bluestop.org (Postfix) with ESMTP id AE2BC7301; Wed, 27 Dec 2017 17:37:19 +0000 (UTC) Received: from muon.bluestop.org ([127.0.0.1]) by muon.bluestop.org (muon.bluestop.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id d2RdyqRhL7nT; Wed, 27 Dec 2017 17:37:19 +0000 (UTC) Received: from [10.0.10.140] (gw.bluestop.org [96.73.9.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by muon.bluestop.org (Postfix) with ESMTPSA; Wed, 27 Dec 2017 17:37:18 +0000 (UTC) Subject: Re: Running dual boot windows inside of bhyve To: Alan Somers , Aryeh Friedman Cc: "freebsd-virtualization@freebsd.org" , FreeBSD Mailing List , FreeBSD Mailing List References: From: Rebecca Cran Message-ID: <7352645c-ecf1-008b-e61a-29b580d1f98c@bluestop.org> Date: Wed, 27 Dec 2017 10:37:18 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 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-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Dec 2017 17:37:28 -0000 On 12/27/2017 10:15 AM, Alan Somers wrote: > > I fear that you may be out of luck. Windows deliberately frustrates this > use case by profiling its hardware at installation time and at every boot > thereafter. If the hardware changes too much, then Windows demands a new > license fee. Moving from physical hardware to a VM would probably trip > every one of its alarms. Fortunately modern versions at least allow you to move the installation to a different machine without requiring a reinstall. You might be told you need to relicense it, and it will take some time to reconfigure itself to the new hardware it finds itself running on, but it'll work at least. -- Rebecca From owner-freebsd-hackers@freebsd.org Wed Dec 27 18:01:57 2017 Return-Path: Delivered-To: freebsd-hackers@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 96908EA4601 for ; Wed, 27 Dec 2017 18:01:57 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5F6BF6F77A; Wed, 27 Dec 2017 18:01:56 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id vBRI1mN3061955; Wed, 27 Dec 2017 10:01:48 -0800 (PST) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id vBRI1maU061954; Wed, 27 Dec 2017 10:01:48 -0800 (PST) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201712271801.vBRI1maU061954@pdx.rh.CN85.dnsmgr.net> Subject: Re: Parsing a comment in stdlib.h In-Reply-To: To: Alan Somers Date: Wed, 27 Dec 2017 10:01:48 -0800 (PST) CC: Eitan Adler , FreeBSD Hackers , gwollman@freebsd.org, Benno Rice X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Mailman-Approved-At: Wed, 27 Dec 2017 18:09:56 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Dec 2017 18:01:57 -0000 > I would say that your proposed change makes it less clear. For one thing, > it's not clear whether those three bullet points are meant to be ANDed or > ORed. For another, I'm not sure why you removed the part about "long > long". Finally, s/its/it's/. Frankly, I think the comment can just be s/it's/it is/ Contractons should not be used in manual pages. > shortened to "C99 functions". GCC and Clang both support "long long". Are > there any external compilers that don't? And I agree, that this change is less clear than the already unclear text that is there. > > On Tue, Dec 26, 2017 at 8:18 PM, Eitan Adler wrote: > > > Hi all, > > > > I'm trying to understand a visibility comment in stdlib.h. Is the > > following change technically correct? > > Can it be made more clear? > > > > Index: include/stdlib.h > > =================================================================== > > --- include/stdlib.h (revision 327228) > > +++ include/stdlib.h (working copy) > > @@ -120,8 +120,10 @@ int wctomb(char *, wchar_t); > > size_t wcstombs(char * __restrict, const wchar_t * __restrict, size_t); > > > > /* > > - * Functions added in C99 which we make conditionally available in the > > - * BSD^C89 namespace if the compiler supports `long long'. > > + * Functions added in C99 which we make available if > > + * - its C99 > > + * - BSD visible and not C89 > > + * - its C++ > > * The #if test is more complicated than it ought to be because > > * __BSD_VISIBLE implies __ISO_C_VISIBLE == 1999 *even if* `long long' > > * is not supported in the compilation environment (which therefore means > > > > > > -- > > Eitan Adler > > _______________________________________________ > > freebsd-hackers@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-hackers@freebsd.org Wed Dec 27 20:44:18 2017 Return-Path: Delivered-To: freebsd-hackers@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 D12AEEAC246; Wed, 27 Dec 2017 20:44:18 +0000 (UTC) (envelope-from hausen@punkt.de) Received: from kagate.punkt.de (kagate.punkt.de [217.29.33.131]) (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 4E87377626; Wed, 27 Dec 2017 20:44:17 +0000 (UTC) (envelope-from hausen@punkt.de) Received: from hugo10.ka.punkt.de (hugo10.ka.punkt.de [217.29.44.10]) by gate2.intern.punkt.de with ESMTP id vBRKfLqY080979; Wed, 27 Dec 2017 21:41:21 +0100 (CET) Received: from [217.29.46.120] ([217.29.46.120]) by hugo10.ka.punkt.de (8.14.2/8.14.2) with ESMTP id vBRKfLqq075013; Wed, 27 Dec 2017 21:41:21 +0100 (CET) (envelope-from hausen@punkt.de) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Running dual boot windows inside of bhyve From: "Patrick M. Hausen" In-Reply-To: Date: Wed, 27 Dec 2017 21:41:20 +0100 Cc: Aryeh Friedman , "freebsd-virtualization@freebsd.org" , FreeBSD Mailing List , FreeBSD Mailing List Content-Transfer-Encoding: quoted-printable Message-Id: <921CAF09-DDCD-43CE-BD45-9F59E7052BBA@punkt.de> References: To: Alan Somers X-Mailer: Apple Mail (2.3273) X-Mailman-Approved-At: Wed, 27 Dec 2017 20:54:00 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Dec 2017 20:44:18 -0000 Hi all, > Am 27.12.2017 um 18:15 schrieb Alan Somers > I fear that you may be out of luck. Windows deliberately frustrates = this > use case by profiling its hardware at installation time and at every = boot > thereafter. If the hardware changes too much, then Windows demands a = new > license fee. Moving from physical hardware to a VM would probably = trip > every one of its alarms. Correct. But we are talking Windows 7 here. It will lose it's activation = for sure, but as far as my experience goes you can always reactivate Windows = 7 with the same keycode (unless it was a counterfeit one and is = intentionally blocked). As a last resort MS offers a phone dialog system that has always worked = for me. > For this reason, I would recommend using a > separate instance for your VM. However, if you do use a shared = instance, > then make sure that your PC is booting in UEFI mode. BHyve can only = boot > Windows in that mode. If you do that, then BHyve will probably be = able to > boot it just fine. This is actually the bigger of the two obstacles. If the original = installation is MBR booting, I don't know of a way to convert it to EFI. If you happen to have some genuine not "OEM" Windows 7 install medium *and* your original key, you should be able to do a fresh installation = and complete activation - via phone if necessary. HTH, Patrick --=20 punkt.de GmbH Internet - Dienstleistungen - Beratung Kaiserallee 13a Tel.: 0721 9109-0 Fax: -100 76133 Karlsruhe info@punkt.de http://punkt.de AG Mannheim 108285 Gf: Juergen Egeling From owner-freebsd-hackers@freebsd.org Wed Dec 27 22:31:15 2017 Return-Path: Delivered-To: freebsd-hackers@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 B54C3E82069; Wed, 27 Dec 2017 22:31:15 +0000 (UTC) (envelope-from cy.schubert@komquats.com) Received: from smtp-out-so.shaw.ca (smtp-out-so.shaw.ca [64.59.136.137]) (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 698DF7B5E1; Wed, 27 Dec 2017 22:31:14 +0000 (UTC) (envelope-from cy.schubert@komquats.com) Received: from spqr.komquats.com ([96.50.22.10]) by shaw.ca with ESMTPA id UKEAemyLhb3YIUKEBeHT9Y; Wed, 27 Dec 2017 15:31:12 -0700 X-Authority-Analysis: v=2.2 cv=J/va1EvS c=1 sm=1 tr=0 a=jvE2nwUzI0ECrNeyr98KWA==:117 a=jvE2nwUzI0ECrNeyr98KWA==:17 a=ocR9PWop10UA:10 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8 a=gG4suzkTnGaVT7dcZ6YA:9 a=Lep1XYZ0wGAbpZAW:21 a=q8-Z87JhJnZApf8S:21 a=CjuIK1q_8ugA:10 a=PLpP4ctxackZs43qJlkA:9 a=FjOSnLTqnpTALeEM:21 a=OqxMexbwkKxuhw4z:21 a=a-Dni1MZVWkbyNyE:21 a=_W_S_7VecoQA:10 a=Ia-lj3WSrqcvXOmTRaiG:22 a=IjZwj45LgO3ly-622nXo:22 Received: from [25.81.38.66] (unknown [24.114.38.70]) by spqr.komquats.com (Postfix) with ESMTPSA id 810548A5; Wed, 27 Dec 2017 14:31:09 -0800 (PST) MIME-Version: 1.0 From: Cy Schubert Subject: RE: Running dual boot windows inside of bhyve Date: Wed, 27 Dec 2017 14:31:20 -0800 To: Rebecca Cran , Alan Somers , Aryeh Friedman CC: "freebsd-virtualization@freebsd.org" , FreeBSD Mailing List , FreeBSD Mailing List Message-Id: <20171227223109.810548A5@spqr.komquats.com> X-CMAE-Envelope: MS4wfEYx265y4VVp/44qoZlDlXaMKzXY3PIaH3fPGmPunZoacvX7qlG3D7n2VDBj203/xA5Wq6htcOnzjyzLGppXz+k+heTAtyFUSyQkiaBeQxb9tFDBIoN6 QEBIw6jgkdBMlOBTii+L8b365E11NFEbxytCg3YUqPJsH8YfKh9ZOJ8dNF8QiG3kGsQ7i05HjoEDLKP+g6Dyall30IkN209TWBSL6//xCYj0nM+BBiY1GYZ7 3O2y6VD+ChELUYnYPLU6bKbGNLi/oQTkbprrjutUdTaqp6rt9DguGhXUPjeeo79NuKpNRgCnLnACSeZ8VEWd1A9qHh+7z46sZK/qYjr3wLdLhgy89JdVyOf7 A5tHq3GzcDaSsMjzlMbCEqW8cPmL1w== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Dec 2017 22:31:15 -0000 I've had no issues when I p2v Windows partitions. In the case of my laptop,= which has 3 FreeBSD partitions and a Windows partition, I've had no licens= ing issues interchangeably booting it under VirtualBox under FreeBSD or on = the bare metal. --- Sent using a tiny phone keyboard. Apologies for any typos and autocorrect. Also, this old phone only supports top post. Apologies. Cy Schubert or The need of the many outweighs the greed of the few. --- -----Original Message----- From: Rebecca Cran Sent: 27/12/2017 09:37 To: Alan Somers; Aryeh Friedman Cc: freebsd-virtualization@freebsd.org; FreeBSD Mailing List; FreeBSD Maili= ng List Subject: Re: Running dual boot windows inside of bhyve On 12/27/2017 10:15 AM, Alan Somers wrote: > > I fear that you may be out of luck. Windows deliberately frustrates this > use case by profiling its hardware at installation time and at every boot > thereafter. If the hardware changes too much, then Windows demands a new > license fee. Moving from physical hardware to a VM would probably trip > every one of its alarms. Fortunately modern versions at least allow you to move the installation=20 to a different machine without requiring a reinstall. You might be told=20 you need to relicense it, and it will take some time to reconfigure=20 itself to the new hardware it finds itself running on, but it'll work at=20 least. --=20 Rebecca _______________________________________________ freebsd-hackers@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@freebsd.org Thu Dec 28 01:16:54 2017 Return-Path: Delivered-To: freebsd-hackers@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 F061EE8BB10; Thu, 28 Dec 2017 01:16:54 +0000 (UTC) (envelope-from stryqx@gmail.com) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (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 B22F41658; Thu, 28 Dec 2017 01:16:54 +0000 (UTC) (envelope-from stryqx@gmail.com) Received: by mail-qk0-x229.google.com with SMTP id j137so30425300qke.10; Wed, 27 Dec 2017 17:16:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=UZJpyVocOmJX/Vhc47NbM1ZiCN3/gpNz6/INICN1fVY=; b=oaD24BNhtnSNnH/3i3N5XZVBLPXV9GryPL4fBbl4E2mNxP5zQ+QgZYXwtL+LGt7r7K jyauowumqY5+5zN/MO8iwBcXKMYpJvZ/OU5BfbJjpTb9prrvuYYkzMndmsNT8QsSILPc mQDJTh9uDd+/xupK/H7yru/GX+47lubpjtiGoSlO/lwDIgkVhfuS3AOEzbxpJpDgsPWk C+XtOrmJkqD9YMt7Qrv0LE4Ie+5bKH6HKbR2rVkcEegg/N3T5AR7Q7ucp2BWxV0+q7Sh lCzh+pINQNZTtXoTPV11tRAZO4pxBCeIWba0EsB50dhhVcl8vuezVzK+VvnKIPvzC+Eg hY0A== 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; bh=UZJpyVocOmJX/Vhc47NbM1ZiCN3/gpNz6/INICN1fVY=; b=GKknDnHDCJ8IwvPUsSpOZz7+PcAAe6Cvp0LAAkC+oc3xZO4czCgpXbok+vVEgMCHn5 tmAPo/8ZQkqvBYyMwujKtAGiMKqnNIJkNMsna+NGH3qtRExZVr2/RwKFvaA7ndfc4XFG FdBgOpOdFCSc8Glrgp1NACwx5OJdDp1+/j6bCdkiezrd0ikIWyNvShR9dVtrGVive3EZ h8k4KrCqx4LZtIztt5tKWCs3nxPerWDEqOyn2PVIeW0P/fLEK5/XUVrxxAaBMNptyr4F WYVvqlq5d6SMBc7FwzU+F3xWHKyPTfD2q5iMzSCFJViiJa3ZXixcJotf80b92bWKWNVi GL/A== X-Gm-Message-State: AKGB3mJIWKDlaE/JT7UUyuuJqtaNtFRiJTcXblFF70Pua9MHpUO1HfK+ TuPWQ4YBYBHvri+idIhsVzTmqDuo0fhN8oz6eB5QlA== X-Google-Smtp-Source: ACJfBov/NEALlfOVWrhU83+0iLg4eBhXJ0NavKyClMIVyDE3QJ0MqwRC/KV2GAt5YwQOLr53JcWf1N8RdT0NJQen5pg= X-Received: by 10.55.143.131 with SMTP id r125mr11203737qkd.215.1514423813574; Wed, 27 Dec 2017 17:16:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.173.136 with HTTP; Wed, 27 Dec 2017 17:16:13 -0800 (PST) In-Reply-To: <20171227223109.810548A5@spqr.komquats.com> References: <20171227223109.810548A5@spqr.komquats.com> From: Chris Knight Date: Thu, 28 Dec 2017 12:16:13 +1100 Message-ID: Subject: Re: Running dual boot windows inside of bhyve To: Cy Schubert Cc: Rebecca Cran , Alan Somers , Aryeh Friedman , "freebsd-virtualization@freebsd.org" , FreeBSD Mailing List , FreeBSD Mailing List Content-Type: text/plain; charset="UTF-8" X-Mailman-Approved-At: Thu, 28 Dec 2017 03:47:42 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Dec 2017 01:16:55 -0000 Howdy, On 28 December 2017 at 09:31, Cy Schubert wrote: > I've had no issues when I p2v Windows partitions. In the case of my laptop, which has 3 FreeBSD partitions and a Windows partition, I've had no licensing issues interchangeably booting it under VirtualBox under FreeBSD or on the bare metal. > Key activation != licensing. Just because you can move it to another machine or P2V it without needing to re-activate it doesn't mean you're licensed to use it either in a VM or on a new machine. Microsoft licensing can be quite opaque, so if you're doing this in a corporate environment make sure you get the appropriate advise to ensure you're properly licensed. From owner-freebsd-hackers@freebsd.org Thu Dec 28 07:28:17 2017 Return-Path: Delivered-To: freebsd-hackers@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 24860EAC501 for ; Thu, 28 Dec 2017 07:28:17 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-yb0-x22c.google.com (mail-yb0-x22c.google.com [IPv6:2607:f8b0:4002:c09::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 E017D6F899 for ; Thu, 28 Dec 2017 07:28:16 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: by mail-yb0-x22c.google.com with SMTP id 5so22447715ybp.4 for ; Wed, 27 Dec 2017 23:28:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=6ILkVC98AIsX90tPQapbjlkd2UEsmuheuq5U4MtG3zQ=; b=OSC6kkF5uL96Pe5aSkU7aEdnqSKl39zQknnPefVFLdGy5YCQw8h+hakgX1lATqOYqo UB5Ein2WUivRJIoqjP+Bk8kWNtGKOMZPEKYfcGd6e31Hh1MPPQGUTouaZAQXrBLwj9C/ E+7eDHWUxAOb/iS8AXt+bHTF6geWBvkXAqun0= 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=6ILkVC98AIsX90tPQapbjlkd2UEsmuheuq5U4MtG3zQ=; b=FXYUZ2jTWhxIuY9tff0EUFSb/naaniMq5WruZFe6I2hyNBTH9EI+Bd+QZLf44etDiW 6DZhhEbNGc7hDfC4vH+mzSosoXbcI63ysWEsRTY1NmFd6DIGy0/QHg++S1XOnv4U1OVz RssdXeA3H0qTPHC59ojFeFZyswSgSOV0KkH7yWEe4hMw4uFKoEGqtq2e4xYbhnIFUAMy XquRpfhkrNntiB+pYU0f/YJeOmxDsXdL0bpSs8ug2ECyZXWQBmR8T6PvLyggOmK39Lae 1IW+gjLe+YzgDsSvRLR5IXzxrZRRl4esPKW7hPXGFfM44o1BAnATi8MlsqjqzE3cvida wacg== X-Gm-Message-State: AKGB3mKlvBjKybpdbhuD5AG/foGOS12+mJsX3htjiric+0lTXq9uZZ/t /ZtQL4p+trE1W5BMc9FmWonrgr+F0SbXR5BC5gitTSzK X-Google-Smtp-Source: ACJfBosEPb5qUc/dV/KgoGWBs1Eo6X2RgJ+7wC8EJc0z0n/NMWhO7JDLOwiJPoDoThReNhCBhiF6rnuJOR9I4mh8I4A= X-Received: by 10.37.210.216 with SMTP id j207mr13472344ybg.517.1514446095841; Wed, 27 Dec 2017 23:28:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.217.21 with HTTP; Wed, 27 Dec 2017 23:27:45 -0800 (PST) In-Reply-To: <8D8CFFA3-ADE9-402F-B9A1-C311E4244FCB@dsl-only.net> References: <8D8CFFA3-ADE9-402F-B9A1-C311E4244FCB@dsl-only.net> From: Eitan Adler Date: Wed, 27 Dec 2017 23:27:45 -0800 Message-ID: Subject: Re: faq/troubleshoot.html#indefinite-wait-buffer has the direction of transfer wrong (head -r326888 /usr/src/) To: Mark Millard Cc: FreeBSD Hackers , FreeBSD Current Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Dec 2017 07:28:17 -0000 On 16 December 2017 at 20:34, Mark Millard wrote: > > On 2017-Dec-16, at 8:23 PM, Eitan Adler wrote: > >> On 16 December 2017 at 10:47, Mark Millard wrot= e: >>> I got a "swap_pager: indefinite wait buffer" notice and looked >>> it up. (This was on a rpi2 booted (kernel and world) from a >>> USB SSD, swap partition in use instead of a swap file. It >>> was building devel/cmake via poudriere-devel .) >>> >>> https://www.freebsd.org/doc/faq/troubleshoot.html#indefinite-wait-buffe= r >>> reads like it is for page-out to disk: >>> >>> >>> QUOTE >>> 5.9. >>> >>> What does the error swap_pager: indefinite wait buffer: mean? >>> >>> This means that a process is trying to page memory to disk, and the pag= e attempt has hung trying to access the disk for more than 20 seconds. It m= ight be caused by bad blocks on the disk drive, disk wiring, cables, or any= other disk I/O-related hardware. If the drive itself is bad, disk errors w= ill appear in /var/log/messages and in the output of dmesg. Otherwise, chec= k the cables and connections. >>> ENDQUOTE >>> >>> >>> But the code containing the message is for "swread": >>> (head -r326888) >> >> If I understand correctly this is fixed by change "trying to page to" >> to "trying to page from" ? In other words this happens on swap-in, >> not swap-out. > > That is my understanding of what I reported. Sorry about the delay: Sending faq/book.xml Transmitting file data .done Committing transaction... Committed revision 51344. Fixed. --=20 Eitan Adler From owner-freebsd-hackers@freebsd.org Thu Dec 28 15:42:56 2017 Return-Path: Delivered-To: freebsd-hackers@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 9F0CCEA5670 for ; Thu, 28 Dec 2017 15:42:56 +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 78DA27FF02 for ; Thu, 28 Dec 2017 15:42:56 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (115-166-0-128.dyn.iinet.net.au [115.166.0.128]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id vBSFghdT004392 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 28 Dec 2017 07:42:48 -0800 (PST) (envelope-from julian@freebsd.org) Subject: Re: Objections to converting bsd-family-tree to a dot file To: Eitan Adler , Maxim Konovalov Cc: FreeBSD Hackers , tech-misc@netbsd.org, Kernel@dragonflybsd.org References: From: Julian Elischer Message-ID: <14e0e227-4d9d-4eba-da1d-90c192bbc251@freebsd.org> Date: Thu, 28 Dec 2017 23:42:37 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.5.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-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Dec 2017 15:42:56 -0000 On 15/12/17 4:51 pm, Eitan Adler wrote: >> Show Me The Money! > See examples at the bottom > > >> How easy would it be to render something like the existing > bsd-family-tree, e.g. something that is reasonably intelligent when > viewed with more(1) or less(1) with the same basic information that > it has now? > > Pretty easy. Examples below. Note its just a first draft. That said, I > did find several unconnected nodes: some of which are corrected in > this version. > >> Also, would rendering it be something that can reasonably > be done while building the system, or would it need to be pre-rendered > and the result checked into the SCM (keep in mind that NetBSD's > build.sh is portable, i.e. you can build NetBSD on Windows if you > feel like it)? > > It'll likely be easier to check it to the repo. It can be done > reasonably portably using graphviz, but its not likely worth it. > > >>> Any objections? It isn't used for much beyond documentation so >>> changing the format isn't expected to cause any negative effects. >>> >> Today it is very simple plaintext thing. For me, the complexity will >> overweight the value of this file. the current manually done file is easy to read. I can't work out if one of the files in the directory you show below is an automatically made version, but the graphically rendered files there are a mess and way harder to read. (and of course not ascii). If there is an ascii generated file that is as easy to read then ok but it's going to have to be VERY good to be more readable that what is there already. > It isn't really complex: > https://people.freebsd.org/~eadler/files/family-tree/by-hand-1.dot.txt > https://people.freebsd.org/~eadler/files/family-tree/ > > > From owner-freebsd-hackers@freebsd.org Fri Dec 29 05:03:21 2017 Return-Path: Delivered-To: freebsd-hackers@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 7AEB2EAA08C for ; Fri, 29 Dec 2017 05:03:21 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-yb0-x230.google.com (mail-yb0-x230.google.com [IPv6:2607:f8b0:4002:c09::230]) (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 44B3E7C2CB for ; Fri, 29 Dec 2017 05:03:21 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: by mail-yb0-x230.google.com with SMTP id j7so23429935ybl.3 for ; Thu, 28 Dec 2017 21:03:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=uhZamrCFskTACkcQuBhezJyyT4WfWG1/GNFFiQCmhPo=; b=t6v/I8aczVtnWTGBY/Xdlsjcl+h89p00qMhx4L9kEYdvQuGS8LlGw/ivEXVEqqoY3q aHCSe8rX6Fpyi5oibAtGJTYxgd0WIIP1ouyK/3VH/72BAG/dS6oazXPtOc3+O58bWr+A ML9H/uTU7bvPBwWlH82tejWxOH85whhdfNiF4= 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; bh=uhZamrCFskTACkcQuBhezJyyT4WfWG1/GNFFiQCmhPo=; b=PM+TSuVSyQf/UqsPfoJ12qf66dCCHFCRjcfPxZGNk3q5vufsfUHU5/vsPcUdLGtJ+E StxWhes0nWzXh0Jz9GHzwZ+nnvBPqnF1njSD04Y2avt+SrUTiNPwAJnktWMfNTcZ4bsR DJVlW06YLMhHaJ5Np57be3D4La7nXb2uTYrdepQ6zBrpkQDqnOom0OiGTqDtZUxvGJan pVgOYUhNrnCF+HhKYza9ts3tCWVAvZQHECu86889RD+Lb6lJkb9h99EpBHjfFOB7bWYL 1wzFsHJo+2/NaBevKFmONe7i6aFu4+F8lOl6dPG8445sQgRGify2ciLrIFyLvnT0f4TA G95g== X-Gm-Message-State: AKGB3mKCZBRT3EkveJi9v34BI9juqfWS0nEmmPWNMCrGtHo9NIOMEbLs crVDc9v3BRir9PxshSMMIbVlPtRmk8s/n7mrO5Bmtw== X-Google-Smtp-Source: ACJfBovP3jH0l8/7WYBjKnmQZRR0EIRx9XdGzs3lWEQ5tO72/SNXZbGyH5ecwmc0t9t2hpTodxdjXvSqS3uoqKtOG/A= X-Received: by 10.37.185.9 with SMTP id x9mr4652876ybj.171.1514523799897; Thu, 28 Dec 2017 21:03:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.217.21 with HTTP; Thu, 28 Dec 2017 21:02:49 -0800 (PST) In-Reply-To: <14e0e227-4d9d-4eba-da1d-90c192bbc251@freebsd.org> References: <14e0e227-4d9d-4eba-da1d-90c192bbc251@freebsd.org> From: Eitan Adler Date: Thu, 28 Dec 2017 21:02:49 -0800 Message-ID: Subject: Re: Objections to converting bsd-family-tree to a dot file To: Julian Elischer Cc: Maxim Konovalov , FreeBSD Hackers , tech-misc@netbsd.org, Kernel@dragonflybsd.org Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Dec 2017 05:03:21 -0000 On 28 December 2017 at 07:42, Julian Elischer wrote: > On 15/12/17 4:51 pm, Eitan Adler wrote: >>> >>> Show Me The Money! >> >> See examples at the bottom >> >> >>> How easy would it be to render something like the existing >> >> bsd-family-tree, e.g. something that is reasonably intelligent when >> viewed with more(1) or less(1) with the same basic information that >> it has now? Alright all. I've dropped the idea. Adding HardnedBSD, TrueOS, and some missing releases manually. -- Eitan Adler From owner-freebsd-hackers@freebsd.org Fri Dec 29 18:19:43 2017 Return-Path: Delivered-To: freebsd-hackers@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 2F361EA9213 for ; Fri, 29 Dec 2017 18:19:43 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from shell1.rawbw.com (shell1.rawbw.com [198.144.192.42]) by mx1.freebsd.org (Postfix) with ESMTP id 06B597469A for ; Fri, 29 Dec 2017 18:19:42 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from yv.noip.me (c-24-6-186-56.hsd1.ca.comcast.net [24.6.186.56]) (authenticated bits=0) by shell1.rawbw.com (8.15.1/8.15.1) with ESMTPSA id vBTIJZAA083137 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Fri, 29 Dec 2017 10:19:36 -0800 (PST) (envelope-from yuri@rawbw.com) X-Authentication-Warning: shell1.rawbw.com: Host c-24-6-186-56.hsd1.ca.comcast.net [24.6.186.56] claimed to be yv.noip.me To: Freebsd hackers list From: Yuri Subject: Is it considered to be ok to not check the return code of close(2) in base? Message-ID: <24acbd94-c52f-e71a-8a96-d608a10963c6@rawbw.com> Date: Fri, 29 Dec 2017 10:19:34 -0800 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Dec 2017 18:19:43 -0000 Some base utilities sometimes close files that they open for their purposes without checking the error code of close(2). Is this considered to be ok, because it's just a close call and we are done with that file descriptor, or is it considered to be more appropriate to check close's error code? Maybe there is some policy that covers this? IMO, every system call's return value should be checked, just in case. Yuri From owner-freebsd-hackers@freebsd.org Fri Dec 29 18:28:36 2017 Return-Path: Delivered-To: freebsd-hackers@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 94644EA99CA for ; Fri, 29 Dec 2017 18:28:36 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1a.eu.mailhop.org (outbound1a.eu.mailhop.org [52.58.109.202]) (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 32B3C74DE7 for ; Fri, 29 Dec 2017 18:28:35 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: ea084504-ecc5-11e7-8dac-d32f5c2d02ef 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 outbound1.eu.mailhop.org (Halon) with ESMTPSA id ea084504-ecc5-11e7-8dac-d32f5c2d02ef; Fri, 29 Dec 2017 18:27:25 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id vBTIRLx8003559; Fri, 29 Dec 2017 11:27:21 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1514572041.12000.7.camel@freebsd.org> Subject: Re: Is it considered to be ok to not check the return code of close(2) in base? From: Ian Lepore To: Yuri , Freebsd hackers list Date: Fri, 29 Dec 2017 11:27:21 -0700 In-Reply-To: <24acbd94-c52f-e71a-8a96-d608a10963c6@rawbw.com> References: <24acbd94-c52f-e71a-8a96-d608a10963c6@rawbw.com> 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-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Dec 2017 18:28:36 -0000 On Fri, 2017-12-29 at 10:19 -0800, Yuri wrote: > Some base utilities sometimes close files that they open for their  > purposes without checking the error code of close(2). > > Is this considered to be ok, because it's just a close call and we > are  > done with that file descriptor, or is it considered to be more  > appropriate to check close's error code? > > Maybe there is some policy that covers this? > > IMO, every system call's return value should be checked, just in > case. > > > Yuri > There's really no point in checking on a close from a file opened only for reading.  You can argue it should be checked on a file open for writing, but often isn't because you're then confronted with the question "what should/can I do if there is an error?"  If you report the error and exit, then what about other files that were open at the time?  They're going to be closed by the kernel as part of process cleanup, with no error checking or reporting. Also, with the async nature of filesystems, IO errors can still happen after the close, unless fsync() was used.  So if you're going to miss most of the errors because of that, why bother to check at all? -- Ian From owner-freebsd-hackers@freebsd.org Fri Dec 29 18:48:47 2017 Return-Path: Delivered-To: freebsd-hackers@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 E051DEAA906 for ; Fri, 29 Dec 2017 18:48:47 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::22a]) (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 EF69C7674A; Fri, 29 Dec 2017 18:48:46 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-lf0-x22a.google.com with SMTP id y78so43214534lfd.1; Fri, 29 Dec 2017 10:48:46 -0800 (PST) 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=M74N0wv+ZzLe3afnIIV0Gmayy2eRaEaVovDSRG8OE2w=; b=OmG4gelruXdEQMUSYAqGnaZJBxo3+EfJlW80cx3Y6k3rkk+WzfCKUTE9kKcvvKUAuu ZoxOXSNmDKU2Vsi5W0iGFpBJOWrUNofHtq31yQ9ykOdJugcZB7UzXSfXSfsipI4BeN3X /lhIuLZT9z0l/wZ05iJgG92UktMwOkzLri4AYC7DexdzC4RaIt1ZaC3VkrcuUCZ09kor tHtN2sPRbGC2xbRohYuNADp71A0ZQ2z+EoZpb45YQANts2bPB0O4XEVscYRfQshXKujc KsNeMF5zS1SkUYqnQbeqT6R+0Yf5FeM3/TVP0EObKhEDx6GJ/ObiWR1sq6sABEl3nfiM eIyA== 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=M74N0wv+ZzLe3afnIIV0Gmayy2eRaEaVovDSRG8OE2w=; b=I5CAgnnPWr/Or7NdIjVDjG1/kfQgwM24JxaiORtkR6+I8XOEae4w6L0PXkJKpxOOC2 4DDepML62lPtV0oUvj6AtmpwvwGY7DxM/jNvUYtBzTcxHsCYfpe0CsUKwGrCkmQExDdI P6LllBQuk9cndW+O3eVtA/GcdLT5qAT7UKL7lNaU4/X2JKBsNgxV87ZOOS1QMVOM5Ww+ OZQNh3vweDeBcOrBZWPYtve7KHEd/qdxYbl35TlaLHkLLyaE6DI6qISd2hQhdVycVb99 qaZPFWOfq3vvq6w3F7bIEfOguQgY5BxkX/oyqQMMu2bEQ8BaO/wjxaCfarkgaFXzsBdj lOhQ== X-Gm-Message-State: AKGB3mJtMCmNVrXlIdi2yImxfMqT4l6tgHjrBs3vqx+nPPfD5/c571oe 7IVOCVn9nlCJ/nWulRAfiJR/CYNXbciqG/d8Ji0= X-Google-Smtp-Source: ACJfBouV7W1sqXKeKegJOK1t7/1LQBZmWf2EY8YZ+ygj1OKvBwR8jvmjgjYgtpVif9IluSWmaSy9YZy2vWa6sSlAXwU= X-Received: by 10.46.27.24 with SMTP id b24mr14282188ljb.54.1514573324184; Fri, 29 Dec 2017 10:48:44 -0800 (PST) MIME-Version: 1.0 Sender: asomers@gmail.com Received: by 10.179.76.19 with HTTP; Fri, 29 Dec 2017 10:48:43 -0800 (PST) In-Reply-To: <1514572041.12000.7.camel@freebsd.org> References: <24acbd94-c52f-e71a-8a96-d608a10963c6@rawbw.com> <1514572041.12000.7.camel@freebsd.org> From: Alan Somers Date: Fri, 29 Dec 2017 11:48:43 -0700 X-Google-Sender-Auth: 3zExsrbv-trUWA07JcYYBim4jO0 Message-ID: Subject: Re: Is it considered to be ok to not check the return code of close(2) in base? To: Ian Lepore Cc: Yuri , Freebsd hackers list Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Dec 2017 18:48:48 -0000 On Fri, Dec 29, 2017 at 11:27 AM, Ian Lepore wrote: > On Fri, 2017-12-29 at 10:19 -0800, Yuri wrote: > > Some base utilities sometimes close files that they open for their > > purposes without checking the error code of close(2). > > > > Is this considered to be ok, because it's just a close call and we > > are > > done with that file descriptor, or is it considered to be more > > appropriate to check close's error code? > > > > Maybe there is some policy that covers this? > > > > IMO, every system call's return value should be checked, just in > > case. > > > > > > Yuri > > > > There's really no point in checking on a close from a file opened only > for reading. You can argue it should be checked on a file open for > writing, but often isn't because you're then confronted with the > question "what should/can I do if there is an error?" If you report > the error and exit, then what about other files that were open at the > time? They're going to be closed by the kernel as part of process > cleanup, with no error checking or reporting. > > Also, with the async nature of filesystems, IO errors can still happen > after the close, unless fsync() was used. So if you're going to miss > most of the errors because of that, why bother to check at all? > > -- Ian > I would argue the opposite. There are very few reasons why close(s) would ever fail, and the most likely is EBADF. EBADF indicates a programming bug, like a double close or use of an uninitialized variable. Those could easily turn into worse bugs in the future. So I think the best course of action is to check the return code, assert() on EBADF, and ignore, or possibly log, other errors. -Alan From owner-freebsd-hackers@freebsd.org Fri Dec 29 20:32:09 2017 Return-Path: Delivered-To: freebsd-hackers@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 E6233EAF094 for ; Fri, 29 Dec 2017 20:32:09 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [78.47.246.247]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 60F897AA5E; Fri, 29 Dec 2017 20:32:08 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221] (may be forged)) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id vBTKW05P040144 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 29 Dec 2017 21:32:00 +0100 (CET) (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: ian@freebsd.org Received: from [10.58.0.4] ([10.58.0.4]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTPS id vBTKVtHJ096928 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 30 Dec 2017 03:31:55 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: Is it considered to be ok to not check the return code of close(2) in base? To: Ian Lepore , Yuri , Freebsd hackers list References: <24acbd94-c52f-e71a-8a96-d608a10963c6@rawbw.com> <1514572041.12000.7.camel@freebsd.org> From: Eugene Grosbein Message-ID: <5A46A638.1060901@grosbein.net> Date: Sat, 30 Dec 2017 03:31:52 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <1514572041.12000.7.camel@freebsd.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=2.2 required=5.0 tests=BAYES_00, LOCAL_FROM, RDNS_NONE autolearn=no autolearn_force=no version=3.4.1 X-Spam-Report: * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 1.9 RDNS_NONE Delivered to internal network by a host with no rDNS * 2.6 LOCAL_FROM From my domains X-Spam-Level: ** X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on hz.grosbein.net X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Dec 2017 20:32:10 -0000 30.12.2017 1:27, Ian Lepore wrote: > There's really no point in checking on a close from a file opened only > for reading. You can argue it should be checked on a file open for > writing, but often isn't because you're then confronted with the > question "what should/can I do if there is an error?" If you report > the error and exit, then what about other files that were open at the > time? They're going to be closed by the kernel as part of process > cleanup, with no error checking or reporting. > > Also, with the async nature of filesystems, IO errors can still happen > after the close, unless fsync() was used. So if you're going to miss > most of the errors because of that, why bother to check at all? Almost any file opened for writing may occur to reside on NFS or some strange FUSE file system or just on removable storage. As general rule, an application should somehow report any file i/o error including close(), especially when data loss can happen due to unflushed buffers. It may be messages written to syslog or stderr with no error checking here to prevent recursion. For example, a word processing application must warn user in any such case and not remove temporary copy, if any etc. It's up to user whether to utilize such async filesystems that lie about success of close() system call. Properly written application should not excuse itself just because of existence of such file systems. Of course, there are cases when that's irrelevant, f.e. closing temporary file that is no more needed and being unlinked anyway. From owner-freebsd-hackers@freebsd.org Fri Dec 29 23:17:52 2017 Return-Path: Delivered-To: freebsd-hackers@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 337EDEB5954 for ; Fri, 29 Dec 2017 23:17:52 +0000 (UTC) (envelope-from bright@mu.org) Received: from elvis.mu.org (pages.mu.org [192.203.228.197]) by mx1.freebsd.org (Postfix) with ESMTP id 24D52805EA; Fri, 29 Dec 2017 23:17:51 +0000 (UTC) (envelope-from bright@mu.org) Received: from Alfreds-MBP-2.lan (c-67-169-71-186.hsd1.ca.comcast.net [67.169.71.186]) by elvis.mu.org (Postfix) with ESMTPSA id 130F010C308A; Fri, 29 Dec 2017 15:17:51 -0800 (PST) Subject: Re: Is it considered to be ok to not check the return code of close(2) in base? To: Ian Lepore , Yuri , Freebsd hackers list References: <24acbd94-c52f-e71a-8a96-d608a10963c6@rawbw.com> <1514572041.12000.7.camel@freebsd.org> From: Alfred Perlstein Message-ID: Date: Fri, 29 Dec 2017 15:17:50 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <1514572041.12000.7.camel@freebsd.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Dec 2017 23:17:52 -0000 On 12/29/17 10:27 AM, Ian Lepore wrote: > On Fri, 2017-12-29 at 10:19 -0800, Yuri wrote: >> Some base utilities sometimes close files that they open for their >> purposes without checking the error code of close(2). >> >> Is this considered to be ok, because it's just a close call and we >> are >> done with that file descriptor, or is it considered to be more >> appropriate to check close's error code? >> >> Maybe there is some policy that covers this? >> >> IMO, every system call's return value should be checked, just in >> case. >> >> >> Yuri >> > There's really no point in checking on a close from a file opened only > for reading.  You can argue it should be checked on a file open for > writing, but often isn't because you're then confronted with the > question "what should/can I do if there is an error?"  If you report > the error and exit, then what about other files that were open at the > time?  They're going to be closed by the kernel as part of process > cleanup, with no error checking or reporting. > > Also, with the async nature of filesystems, IO errors can still happen > after the close, unless fsync() was used.  So if you're going to miss > most of the errors because of that, why bother to check at all? > A file open for writing should be tested on close for NFS and other filesystems that have "fsync on close" semantics. -Alfred From owner-freebsd-hackers@freebsd.org Sat Dec 30 00:19:03 2017 Return-Path: Delivered-To: freebsd-hackers@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 5BAFCE8511C for ; Sat, 30 Dec 2017 00:19:03 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-164.reflexion.net [208.70.210.164]) (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 059283FD9 for ; Sat, 30 Dec 2017 00:19:02 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 332 invoked from network); 30 Dec 2017 00:18:56 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 30 Dec 2017 00:18:56 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Fri, 29 Dec 2017 19:18:56 -0500 (EST) Received: (qmail 20260 invoked from network); 30 Dec 2017 00:18:55 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 30 Dec 2017 00:18:55 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id E19BCEC9398; Fri, 29 Dec 2017 16:18:54 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Is the clang 5.0.1 use of .rela.plt and R_PPC64_JMP_SLOT for kernel modules a llvm issue? Just a FreeBSD one? From: Mark Millard In-Reply-To: Date: Fri, 29 Dec 2017 16:18:54 -0800 Cc: FreeBSD PowerPC ML , FreeBSD Hackers Content-Transfer-Encoding: quoted-printable Message-Id: <2BD5FD21-95E7-4661-B8B9-2FDCDB986149@dsl-only.net> References: <39C042C5-9800-464C-84AC-677DB45DA1C1@dsl-only.net> <244D5C85-E1E7-4349-A46A-1D275D54833F@dsl-only.net> <55A9388E-2C04-4388-A4E9-F25574FAF129@dsl-only.net> <68EA105F-3ADF-4CBB-BD59-7A9F18E52DB3@dsl-only.net> <313C2310-ABEF-4BEE-A853-A9965680C3AC@dsl-only.net> To: Ed Maste , Dimitry Andric , Justin Hibbits , Nathan Whitehorn X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Dec 2017 00:19:03 -0000 I've not been able to figure out if I should submit something into llvm's bugzilla for the powerpc64 switching to .rela.plt and R_PPC64_JMP_SLOT for kernel modules from the earlier .rela.dyn and R/PPC64_RELATIVE and R_PPC64_ADDR64 for kernel modules. (I do not know if powerpc would also have the issue since other things have been stopping that build for a long time.) Do one or more of you have a clue? Reminder: I have submitted FreeBSD bugzilla 224561 for the issue. The difference in the likes of filemon.ko produced by system clang 5.0.1 vs. devel/powerpc64-xtoolchain-gcc is. . . clang 5.0.1: Relocation section with addend (.rela.plt): r_offset r_info r_type st_value st_name + = r_addend 000000014480 000300000015 R_PPC64_JMP_SLOT 0000000000000000 copyinstr = + 0 000000014488 000400000015 R_PPC64_JMP_SLOT 0000000000000000 = devfs_set_cdevpriv + 0 . . . vs. devel/powerpc64-xtoolchain-gcc: Relocation section with addend (.rela.dyn): r_offset r_info r_type st_value st_name + = r_addend 0000000145c0 000000000016 R_PPC64_RELATIVE 0000000000000000 + 40d0 0000000145e0 000000000016 R_PPC64_RELATIVE 0000000000000000 + 145b0 . . . 000000014408 000600000026 R_PPC64_ADDR64 0000000000000000 sysent + = 0 000000014410 001100000026 R_PPC64_ADDR64 0000000000000000 = freebsd32_sysent + 0 Apparently R_PPC64_JMP_SLOT is mishandled and does not explicitly lead to rejection of the attempted dynamic load. It might be an issue if .rela.plt and R_PPC64_JMP_SLOT should even be generated instead of .rela.dyn and R_PPC64_RELATIVE and R_PPC64_ADDR64. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-hackers@freebsd.org Fri Dec 29 23:27:04 2017 Return-Path: Delivered-To: freebsd-hackers@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 B0A9FEB5F25 for ; Fri, 29 Dec 2017 23:27:04 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 7756F80AC8 for ; Fri, 29 Dec 2017 23:27:03 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.55.3]) by phk.freebsd.dk (Postfix) with ESMTP id EF98827378; Fri, 29 Dec 2017 23:26:55 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.15.2/8.15.2) with ESMTPS id vBTNQejt048625 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 29 Dec 2017 23:26:40 GMT (envelope-from phk@critter.freebsd.dk) Received: (from phk@localhost) by critter.freebsd.dk (8.15.2/8.15.2/Submit) id vBTNQd8e048624; Fri, 29 Dec 2017 23:26:39 GMT (envelope-from phk) To: Yuri cc: Freebsd hackers list Subject: Re: Is it considered to be ok to not check the return code of close(2) in base? In-reply-to: <24acbd94-c52f-e71a-8a96-d608a10963c6@rawbw.com> From: "Poul-Henning Kamp" References: <24acbd94-c52f-e71a-8a96-d608a10963c6@rawbw.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <48622.1514589999.1@critter.freebsd.dk> Date: Fri, 29 Dec 2017 23:26:39 +0000 Message-ID: <48623.1514589999@critter.freebsd.dk> X-Mailman-Approved-At: Sat, 30 Dec 2017 00:55:59 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Dec 2017 23:27:04 -0000 -------- In message <24acbd94-c52f-e71a-8a96-d608a10963c6@rawbw.com>, Yuri writes: >Some base utilities sometimes close files that they open for their >purposes without checking the error code of close(2). My personal policy has become to always assert the return value of close(2) calls and to leave the asserts in the production code since they cost nothing in practice. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-hackers@freebsd.org Sat Dec 30 14:39:22 2017 Return-Path: Delivered-To: freebsd-hackers@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 2EB5CE8843D for ; Sat, 30 Dec 2017 14:39:22 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [78.47.246.247]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 9F6F67E56D; Sat, 30 Dec 2017 14:39:21 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221] (may be forged)) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id vBUEd7ad048390 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 30 Dec 2017 15:39:08 +0100 (CET) (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: freebsd-rwg@pdx.rh.CN85.dnsmgr.net Received: from [10.58.0.4] ([10.58.0.4]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTPS id vBUEd3l8004723 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 30 Dec 2017 21:39:03 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: Is it considered to be ok to not check the return code of close(2) in base? To: "Rodney W. Grimes" References: <201712301406.vBUE68qD076011@pdx.rh.CN85.dnsmgr.net> Cc: Ian Lepore , Yuri , Freebsd hackers list From: Eugene Grosbein Message-ID: <5A47A504.1030901@grosbein.net> Date: Sat, 30 Dec 2017 21:39:00 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <201712301406.vBUE68qD076011@pdx.rh.CN85.dnsmgr.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=2.2 required=5.0 tests=BAYES_00, LOCAL_FROM, RDNS_NONE autolearn=no autolearn_force=no version=3.4.1 X-Spam-Report: * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 1.9 RDNS_NONE Delivered to internal network by a host with no rDNS * 2.6 LOCAL_FROM From my domains X-Spam-Level: ** X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on hz.grosbein.net X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Dec 2017 14:39:22 -0000 30.12.2017 21:06, Rodney W. Grimes wrote: >> Of course, there are cases when that's irrelevant, f.e. closing temporary file >> that is no more needed and being unlinked anyway. > > No error on close should be treated as irreleveant, they signify something > has gone wrong and itis best to inform the user and let the user decide > if this is irrelevant or not. > > Code that does not test return codes from EVERY single thing that can > return an error should be taken out back shown the danish axe, clean it > up or get it out of our tree! An application checks for error code after writing to stderr to report an error and finds it failed too; and what should be done then? :-) > One should never code to the "normal" conditions situation, it makes for > code that does not work well when the "abnormal" conditions arrise. > In real world, there are cases of temporary errors like some transient system resource shortage; application's own short timeout on close() because of NFS-server responding slow due to short network malfunction; temporary DNS failure etc. Not every such case deserves user attention as system must have some level of self-healing (retry, disregard etc.) > I would argue that in the above sample of "closing and unlinking" it > would actually be better to exit if the close failed possibly leaving > behind the evidence of why/what failed rather than blindling forging > ahead and potentially destroying the evidecnce by unlinking the file. > > If someone wants to go chasing after "failure to check exit codes" please > begin with /etc/rc.d/*, these scripts are so full of it I laugh every > time I see a system come up multiuser after 10+ errors have happendend > in them. Mostly it is NOT better to halt and sit instead of proceeding to multiuser anyway. From owner-freebsd-hackers@freebsd.org Sat Dec 30 14:06:19 2017 Return-Path: Delivered-To: freebsd-hackers@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 4F508E86D99 for ; Sat, 30 Dec 2017 14:06:19 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2915E7D705; Sat, 30 Dec 2017 14:06:18 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id vBUE6AM5076012; Sat, 30 Dec 2017 06:06:10 -0800 (PST) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id vBUE68qD076011; Sat, 30 Dec 2017 06:06:08 -0800 (PST) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201712301406.vBUE68qD076011@pdx.rh.CN85.dnsmgr.net> Subject: Re: Is it considered to be ok to not check the return code of close(2) in base? In-Reply-To: <5A46A638.1060901@grosbein.net> To: Eugene Grosbein Date: Sat, 30 Dec 2017 06:06:08 -0800 (PST) CC: Ian Lepore , Yuri , Freebsd hackers list X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Mailman-Approved-At: Sat, 30 Dec 2017 15:25:55 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Dec 2017 14:06:19 -0000 > 30.12.2017 1:27, Ian Lepore wrote: > > > There's really no point in checking on a close from a file opened only > > for reading. You can argue it should be checked on a file open for > > writing, but often isn't because you're then confronted with the > > question "what should/can I do if there is an error?" If you report > > the error and exit, then what about other files that were open at the > > time? They're going to be closed by the kernel as part of process > > cleanup, with no error checking or reporting. > > > > Also, with the async nature of filesystems, IO errors can still happen > > after the close, unless fsync() was used. So if you're going to miss > > most of the errors because of that, why bother to check at all? > > Almost any file opened for writing may occur to reside on NFS > or some strange FUSE file system or just on removable storage. > > As general rule, an application should somehow report any file i/o error > including close(), especially when data loss can happen due to unflushed buffers. > > It may be messages written to syslog or stderr with no error checking here > to prevent recursion. For example, a word processing application must warn > user in any such case and not remove temporary copy, if any etc. > > It's up to user whether to utilize such async filesystems that lie about > success of close() system call. Properly written application should not excuse itself > just because of existence of such file systems. > > Of course, there are cases when that's irrelevant, f.e. closing temporary file > that is no more needed and being unlinked anyway. No error on close should be treated as irreleveant, they signify something has gone wrong and itis best to inform the user and let the user decide if this is irrelevant or not. Code that does not test return codes from EVERY single thing that can return an error should be taken out back shown the danish axe, clean it up or get it out of our tree! One should never code to the "normal" conditions situation, it makes for code that does not work well when the "abnormal" conditions arrise. I would argue that in the above sample of "closing and unlinking" it would actually be better to exit if the close failed possibly leaving behind the evidence of why/what failed rather than blindling forging ahead and potentially destroying the evidecnce by unlinking the file. If someone wants to go chasing after "failure to check exit codes" please begin with /etc/rc.d/*, these scripts are so full of it I laugh every time I see a system come up multiuser after 10+ errors have happendend in them. -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-hackers@freebsd.org Sat Dec 30 15:44:59 2017 Return-Path: Delivered-To: freebsd-hackers@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 BD94BE8B919 for ; Sat, 30 Dec 2017 15:44:59 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A611880D37; Sat, 30 Dec 2017 15:44:59 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id vBUFivX2076429; Sat, 30 Dec 2017 07:44:57 -0800 (PST) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id vBUFivES076428; Sat, 30 Dec 2017 07:44:57 -0800 (PST) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201712301544.vBUFivES076428@pdx.rh.CN85.dnsmgr.net> Subject: Re: Is it considered to be ok to not check the return code of close(2) in base? In-Reply-To: <5A47A504.1030901@grosbein.net> To: Eugene Grosbein Date: Sat, 30 Dec 2017 07:44:57 -0800 (PST) CC: Ian Lepore , Yuri , Freebsd hackers list X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Mailman-Approved-At: Sat, 30 Dec 2017 17:01:14 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Dec 2017 15:44:59 -0000 [ Charset windows-1252 unsupported, converting... ] > 30.12.2017 21:06, Rodney W. Grimes wrote: > > >> Of course, there are cases when that's irrelevant, f.e. closing temporary file > >> that is no more needed and being unlinked anyway. > > > > No error on close should be treated as irreleveant, they signify something > > has gone wrong and itis best to inform the user and let the user decide > > if this is irrelevant or not. > > > > Code that does not test return codes from EVERY single thing that can > > return an error should be taken out back shown the danish axe, clean it > > up or get it out of our tree! > > An application checks for error code after writing to stderr to report an error > and finds it failed too; and what should be done then? :-) One should do the right thing, you know that this is a case of the output to stderr failed, and that it would not be right to try to output another error, but probably just call exit with a non zero value so that the caller may be able to do something with that data. Your trying to over complicate what is a very simple rule, if a status can be returned, one should check it and try to do the best thing possible. Or maybe we should just turn off the compiler warning that flags this? > > > One should never code to the "normal" conditions situation, it makes for > > code that does not work well when the "abnormal" conditions arrise. > > > > In real world, there are cases of temporary errors like some transient > system resource shortage; application's own short timeout on close() > because of NFS-server responding slow due to short network malfunction; > temporary DNS failure etc. Not every such case deserves user attention > as system must have some level of self-healing (retry, disregard etc.) And silently ignoring these transient conditons is right in what way? Weeee.. lets silently not tell the user that his data may not be there cause we had a transient error condition? > > > I would argue that in the above sample of "closing and unlinking" it > > would actually be better to exit if the close failed possibly leaving > > behind the evidence of why/what failed rather than blindling forging > > ahead and potentially destroying the evidecnce by unlinking the file. > > > > If someone wants to go chasing after "failure to check exit codes" please > > begin with /etc/rc.d/*, these scripts are so full of it I laugh every > > time I see a system come up multiuser after 10+ errors have happendend > > in them. > > Mostly it is NOT better to halt and sit instead of proceeding to multiuser anyway. >From a security standpooint it IS better to halt and sit instead, as some important security aspect may not be correct now because we blazed ahead ignoring errors!!!!! It is also senseless to go forward if /usr is missing cause of some mess up, as then there well be no /usr/lib/getty and most likely no one is going to be able to login anyway, necessatating the need to do either an ACPI poweroff event, ctl-alt-del event, or god forbit hard power down, followed by a reboot to single user to fix the issues almost always leaving you with dirty file systems and other not so nice things. -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-hackers@freebsd.org Sat Dec 30 17:16:22 2017 Return-Path: Delivered-To: freebsd-hackers@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 E2778EA3093 for ; Sat, 30 Dec 2017 17:16:22 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1b.ore.mailhop.org (outbound1b.ore.mailhop.org [54.200.247.200]) (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 C624463591 for ; Sat, 30 Dec 2017 17:16:22 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 1bbdb620-ed85-11e7-8486-0934409070aa 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 outbound1.ore.mailhop.org (Halon) with ESMTPSA id 1bbdb620-ed85-11e7-8486-0934409070aa; Sat, 30 Dec 2017 17:16:01 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id vBUHGEqr005863; Sat, 30 Dec 2017 10:16:14 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1514654174.12000.15.camel@freebsd.org> Subject: Re: Is it considered to be ok to not check the return code of close(2) in base? From: Ian Lepore To: "Rodney W. Grimes" , Eugene Grosbein Cc: Yuri , Freebsd hackers list Date: Sat, 30 Dec 2017 10:16:14 -0700 In-Reply-To: <201712301544.vBUFivES076428@pdx.rh.CN85.dnsmgr.net> References: <201712301544.vBUFivES076428@pdx.rh.CN85.dnsmgr.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-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Dec 2017 17:16:23 -0000 On Sat, 2017-12-30 at 07:44 -0800, Rodney W. Grimes wrote: > [ Charset windows-1252 unsupported, converting... ] > > > > > 30.12.2017 21:06, Rodney W. Grimes wrote: > > > > > > > > > > > > > Of course, there are cases when that's irrelevant, f.e. closing temporary file > > > > that is no more needed and being unlinked anyway. > > > No error on close should be treated as irreleveant, they signify something > > > has gone wrong and itis best to inform the user and let the user decide > > > if this is irrelevant or not. > > > > > > Code that does not test return codes from EVERY single thing that can > > > return an error should be taken out back shown the danish axe, clean it > > > up or get it out of our tree! > > An application checks for error code after writing to stderr to report an error > > and finds it failed too; and what should be done then? :-) > One should do the right thing, you know that this is a case of the > output to stderr failed, and that it would not be right to try to > output another error, but probably just call exit with a non zero > value so that the caller may be able to do something with that > data. > > Your trying to over complicate what is a very simple rule, if a status > can be returned, one should check it and try to do the best thing possible. > Or maybe we should just turn off the compiler warning that flags this? No, you're trying to impose a ridiculously simple rule onto what is inherently a complex situation.  The idea that every close() should be checked is just ludicrous.  What about output to stdout?  Does a program under your rules explicitly need to close() stdout and check the return code?  If not, justify how a failure to write to stdout in a typical unix pipeline-oriented tool is less important than writes directly to a disk file.  How about stderr?  If that fails, what do you do? Even the earlier simplistic notion that all close() calls should be asserted still overlooks the fact that virtually every application has multiple files open, and if an assert triggers on one close(), none of the other closes (perhaps equally or more important ones) will ever get checked or reported.  Writing code into every simple tool to handle failures of close() without short-cutting the checking of following closes and cleanup work would just be an absurd waste of time. -- Ian From owner-freebsd-hackers@freebsd.org Sat Dec 30 17:29:44 2017 Return-Path: Delivered-To: freebsd-hackers@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 54BC6EA3C4F for ; Sat, 30 Dec 2017 17:29:44 +0000 (UTC) (envelope-from lm@mcvoy.com) Received: from mcvoy.com (mcvoy.com [192.169.23.250]) (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 42CC963D4A; Sat, 30 Dec 2017 17:29:44 +0000 (UTC) (envelope-from lm@mcvoy.com) Received: by mcvoy.com (Postfix, from userid 3546) id 2466235E0DC; Sat, 30 Dec 2017 09:20:47 -0800 (PST) Date: Sat, 30 Dec 2017 09:20:47 -0800 From: Larry McVoy To: Ian Lepore Cc: "Rodney W. Grimes" , Eugene Grosbein , Yuri , Freebsd hackers list Subject: Re: Is it considered to be ok to not check the return code of close(2) in base? Message-ID: <20171230172047.GK22177@mcvoy.com> References: <201712301544.vBUFivES076428@pdx.rh.CN85.dnsmgr.net> <1514654174.12000.15.camel@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1514654174.12000.15.camel@freebsd.org> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Dec 2017 17:29:44 -0000 On Sat, Dec 30, 2017 at 10:16:14AM -0700, Ian Lepore wrote: > On Sat, 2017-12-30 at 07:44 -0800, Rodney W. Grimes wrote: > > [ Charset windows-1252 unsupported, converting... ] > > > > > > > > 30.12.2017 21:06, Rodney W. Grimes wrote: > > > > > > > > > > > > > > > > > Of course, there are cases when that's irrelevant, f.e. closing temporary file > > > > > that is no more needed and being unlinked anyway. > > > > No error on close should be treated as irreleveant, they signify something > > > > has gone wrong and itis best to inform the user and let the user decide > > > > if this is irrelevant or not. > > > > > > > > Code that does not test return codes from EVERY single thing that can > > > > return an error should be taken out back shown the danish axe, clean it > > > > up or get it out of our tree! > > > An application checks for error code after writing to stderr to report an error > > > and finds it failed too; and what should be done then? :-) > > One should do the right thing, you know that this is a case of the > > output to stderr failed, and that it would not be right to try to > > output another error, but probably just call exit with a non zero > > value so that the caller may be able to do something with that > > data. > > > > Your trying to over complicate what is a very simple rule, if a status > > can be returned, one should check it and try to do the best thing possible. > > Or maybe we should just turn off the compiler warning that flags this? > > No, you're trying to impose a ridiculously simple rule onto what is > inherently a complex situation. ?The idea that every close() should be > checked is just ludicrous. ?What about output to stdout? ?Does a > program under your rules explicitly need to close() stdout and check > the return code? ?If not, justify how a failure to write to stdout in a > typical unix pipeline-oriented tool is less important than writes > directly to a disk file. ?How about stderr? ?If that fails, what do you > do? > > Even the earlier simplistic notion that all close() calls should be > asserted still overlooks the fact that virtually every application has > multiple files open, and if an assert triggers on one close(), none of > the other closes (perhaps equally or more important ones) will ever get > checked or reported. ?Writing code into every simple tool to handle > failures of close() without short-cutting the checking of following > closes and cleanup work would just be an absurd waste of time. Gonna side with Ian on this one. I took my queues from Rochkind (I think that's who it was) that wrote the Advanced Unix Programming - when I read that I was amazed at how many error returns he didn't check. I slowly learned that he checked the ones that could throw errors where he could do something about it and ignored the other ones. Mindlessly checking everything leads to dumb programming. I've seen the same thing in POSIX compliance testing. Zillions and zillions of mindless tests that somehow manage to not test the stuff that needs testing.