From owner-freebsd-hackers@freebsd.org Sat May 13 22:30:39 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 8FD54D66D9E; Sat, 13 May 2017 22:30:39 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail104.syd.optusnet.com.au (mail104.syd.optusnet.com.au [211.29.132.246]) by mx1.freebsd.org (Postfix) with ESMTP id 33B216EC; Sat, 13 May 2017 22:30:38 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from besplex.bde.org (c122-106-153-191.carlnfd1.nsw.optusnet.com.au [122.106.153.191]) by mail104.syd.optusnet.com.au (Postfix) with ESMTPS id AEF9E4296A3; Sun, 14 May 2017 08:30:35 +1000 (AEST) Date: Sun, 14 May 2017 08:30:34 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Steve Kargl cc: freebsd-hackers@freebsd.org, freebsd-numerics@freebsd.org Subject: Re: Implementation of half-cycle trignometric functions In-Reply-To: <20170513205517.GA91911@troutmask.apl.washington.edu> Message-ID: <20170514071942.T1084@besplex.bde.org> References: <20170428010122.GA12814@troutmask.apl.washington.edu> <20170428183733.V1497@besplex.bde.org> <20170428165658.GA17560@troutmask.apl.washington.edu> <20170429035131.E3406@besplex.bde.org> <20170428201522.GA32785@troutmask.apl.washington.edu> <20170429070036.A4005@besplex.bde.org> <20170428233552.GA34580@troutmask.apl.washington.edu> <20170429005924.GA37947@troutmask.apl.washington.edu> <20170429151457.F809@besplex.bde.org> <20170429194239.P3294@besplex.bde.org> <20170513205517.GA91911@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.2 cv=KeqiiUQD c=1 sm=1 tr=0 a=Tj3pCpwHnMupdyZSltBt7Q==:117 a=Tj3pCpwHnMupdyZSltBt7Q==:17 a=kj9zAlcOel0A:10 a=YHl6NKQVYIZzuSoSgCMA:9 a=viboGBD9vYLM4oiE:21 a=fNZ8f2z6azax7mVy:21 a=CjuIK1q_8ugA:10 X-Mailman-Approved-At: Sun, 14 May 2017 02:26:45 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 May 2017 22:30:39 -0000 On Sat, 13 May 2017, Steve Kargl wrote: > On Sat, Apr 29, 2017 at 08:19:23PM +1000, Bruce Evans wrote: >> ... >> Using the standard kernels is easy and works well: > > Maybe works well. See below. >> ... >> Anywyay, it looks like the cost of using the kernel is at most 8-9 >> in the parallel case and at most 30 in the serial case. The extra- >> precision code has about 10 dependent instructions, so it s is >> doing OK to take 30. Probably a few more than 8. I got nowhere using inline versions for double precision. Apparently the only large win for inlining is when it avoids repeating the classification, as it does for e_rem_pio2*. The kernels don't repeat anything, so the only cost a function call, plus a few cycles for testing iy for __kernel_sin() only. > Based on other replies in this email exchange, I have gone back > and looked at improvements to my __kernel_{cos|sin|tan}pi[fl] > routines. The improvements where for both accuracy and speed. I really don't want another set of kernels (or more sets for degrees instead of radians, and sincos). Improvements to the existing kernels are welcome, but difficult except for long double precision. I got nowhere tweaking the polynominal in __kernel_sin(). Every change that that I tried just moved the tradeoff between accuracy and efficiency. The one best for efficiency is only about 4 cycles faster, and increases the error by 0.1 to 0.2 ulps. This change involves adding up the terms in a different order. > I have tested on i686 and x86_64 systems with libm built with > -O2 -march=native -mtune=native. My timing loop is of the > form > > float dx, f, x; > long i, k; > > f = 0; > k = 1 << 23; > dx = (xmax - xmin) / (k - 1); > time_start(); > for (i = 0; i < k; i++) { > x = xmin + i * dx; This asks for a conversions from long to double which tends to be slow, and a multiplication in the inner loop. The compiler shouldn't optimize it to x += dx since this has different inaccuracy. My test loop does x += dx with FP an test that x < limit. This sometimes has problems when dx is so small that x + dx == x. Also, x, dx and limit are double precision for testing all precision, so that the loop overhead is the same for all precisions. This works best on i386/i387. Otherwise, there are larger conversion overheads. This usually prevents x + dx == x in float precision, but in long double precison it results in x + dx == x more often. Double precision just can't handle a large limit like LDBL_MAX or even small steps up to DBL_MAX. > f += cospif(x); > }; > time_end(); > > x = (time_cpu() / k) * 1.e6; > printf("cospif time: %.4f usec per call\n", x); > > if (f == 0) > printf("Can't happen!\n"); Otherwise, this is a reasonable throughput test. But please count times in cycles if possible. rdtsc() is very easy to use on x86. > > The assumption here is that loop overhead is the same for > all tested kernels. It is probably much larger for long double precision. I get minimal times like 9 cycles for float and double precision, but more like 30 for long double on x86. > Test intervals for kernels. > > float: [0x1p-14, 0.25] > double: [0x1p-29, 0.25] > ld80: [0x1p-34, 0.25] > > Core2 Duo T7250 @ 2.00GHz || AMD FX8350 Eight-Core CPU > (1995.05-MHz 686-class) || (4018.34-MHz K8-class) > ----------------------------------++-------------------------- > | Horner | Estrin | Fdlibm || Horner | Estrin | Fdlibm > -------+--------+--------+--------++--------+--------+-------- > cospif | 0.0223 | | 0.0325 || 0.0112 | | 0.0085 > sinpif | 0.0233 | Note 1 | 0.0309 || 0.0125 | | 0.0085 > tanpif | 0.0340 | | Note 2 || 0.0222 | | The fdlibm kernels are almost impossible to beat in float precision, since they use double precision so the correct way to use them is for example 'cospif: return __kernel_cosdf(M_PI * x);' after reduction to |x| ~< 0.25 Any pure float precision method is going to take 10-20 cycles longer. It is interesting that you measured fdlibm to be faster on the newer system but much slower on the older system. The latter must be a bug somewhere. > -------+--------+--------+--------++--------+--------+-------- > cospi | 0.0641 | 0.0571 | 0.0604 || 0.0157 | 0.0142 | 0.0149 > sinpi | 0.0722 | 0.0626 | 0.0712 || 0.0178 | 0.0161 | 0.0166 > tanpi | 0.1049 | 0.0801 | || 0.0323 | 0.0238 | > -------+--------+--------+--------++--------+--------+-------- Now the differences are almost small enough to be noise. > cospil | 0.0817 | 0.0716 | 0.0921 || 0.0558 | 0.0560 | 0.0755 > sinpil | 0.0951 | 0.0847 | 0.0994 || 0.0627 | 0.0568 | 0.0768 > tanpil | 0.1310 | 0.1004 | || 0.1005 | 0.0827 | > -------+--------+--------+--------++--------+--------+-------- Now the differences are that the kernels for long double precision are unoptimized. They use Horner. Actually, they do use the optimization of using double precision constants if possible (but not the larger optimization for sparc64 of calculating higher terms in double precision). > Time in usec/call. > > Note 1. In re-arranging the polynomials for Estrin's method and > float, I found appreciable benefit. Do you mean "no appreciable benefit"? No times are shown. Short polynomials benefit less. There is also the problem that measuring throughput vs latency is hard. If the CPU can execute several functions in parallel, it is best (iff the load has candidates for such functions, as simple tests do) to use something like Horner's method to minimise the number of operations. Horner's method is only very bad for latency, and on in-order CPUs. Some of the timing anomalys are probably explained by this -- newer CPUs have fewer bottlenecks so do better at executing functions in parallel; this is also easier in float precision. > Note 2. I have been unable to use the tan[fl] kernels to implement > satisfactory kernels for tanpi[fl]. In particular, for x in [0.25,0.5] > and using tanf kernel leads to 6 digit ULPs in 0.5 whereas my kernel > near 2 ULP. The tanf kernel should be very accurate since it is in double precision. But its polynomial is chosen to only give an accuracy of 0.7999 ulps, while the polys for cosf and sing are chosen to give an accuracy of 0.5009 ulps, since the high accuracy is only almost free for the latter. Any extra error on 0.7999 might be too much. But multiplication by M_PI in double precision shouldn't change the error by more than 0.0001 ulps. The tanl kernel has to struggle to get even sub-ulp precision. Its degree is too high for efficiency, and I don't trust it to give even sub-ulp precision, especially for ld128. I didn't manage to get cospi(x) and sinpi(x) using the kernels as fast as cos(x) and sin(x), even with |x| restricted to < 0.25 so that the range reduction step is null. The extra precision operations just take longer than the range reduction even when the latter is not simplifed for the reduced range. Conversion of degrees to multiples of Pi is interesting. E.g., cosd(x) = cos(x * Pi / 180) = cospi(x / 180) in infinite precision. The natural way to implement it is to convert to cospi() first. This is only easy using a remainder operation. Remainder operations work for this, unlike for converting radians to a quadrand plus a remainder, because 180 is exactly representable but Pi isn't. But exact remainder operations are slow too. They are just not as slow or inexact as ones for 18000+ digit approximations to Pi. So cosd(x) can only be implemented much more efficiently than cos(x) for the unimportant case of large |x|. Bruce From owner-freebsd-hackers@freebsd.org Sun May 14 05:35: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 C7283D6C1E8 for ; Sun, 14 May 2017 05:35:23 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id AC262CF for ; Sun, 14 May 2017 05:35:23 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id v4E5ZHAu094492 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 13 May 2017 22:35:17 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id v4E5ZGnZ094491; Sat, 13 May 2017 22:35:16 -0700 (PDT) (envelope-from sgk) Date: Sat, 13 May 2017 22:35:16 -0700 From: Steve Kargl To: Konstantin Belousov Cc: freebsd-hackers@freebsd.org Subject: Re: mutex owned? Message-ID: <20170514053516.GA94476@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu References: <20170513010459.GA83399@troutmask.apl.washington.edu> <20170513123836.GY1622@kib.kiev.ua> <20170513160822.GA88653@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170513160822.GA88653@troutmask.apl.washington.edu> User-Agent: Mutt/1.7.2 (2016-11-26) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 May 2017 05:35:23 -0000 On Sat, May 13, 2017 at 09:08:22AM -0700, Steve Kargl wrote: > On Sat, May 13, 2017 at 03:38:37PM +0300, Konstantin Belousov wrote: > > On Fri, May 12, 2017 at 06:04:59PM -0700, Steve Kargl wrote: > > > So, after 6 to 8 hours of building libreoffice, I run into this > > > > > > Abort trap (core dumped) > > > OK (1) > > > Fatal error 'mutex 0x2beaa340 own 0x189be is on list 0x69004c 0x74006e' at line 153 in file /mnt/src/lib/libthr/thread/thr_mutex.c (errno = 0) > > > > > > No core file identified in directory /usr/ports/editors/libreoffice/work/libreoffice-5.2.7.2/workdir/CppunitTest/dbaccess_dialog_save.test.core > > > To show backtraces for crashes during test execution, > > > enable core files with: > > > > > > ulimit -c unlimited > > > > > > > > > Is there a known issue with libthr on i686? > > > > I am not aware. > > > > Please ensure that your libthr and libc are built with debugging symbols > > (default on HEAD), obtain core dump and show me the backtrace, for the > > start. > > I tried getting a core by restarting the build in editor/libreoffice > with 'make -DNOCLEAN'. The build then completed without error. I'll > restart from a clean directory and see what happens. > Rebuilt libreoffice without a problem. The system was under load when the core happened, but not too loaded with the recent build. Perhaps, a heisenbug. -- Steve 20170425 https://www.youtube.com/watch?v=VWUpyCsUKR4 20161221 https://www.youtube.com/watch?v=IbCHE-hONow From owner-freebsd-hackers@freebsd.org Sun May 14 08:19: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 23911D6C8D8; Sun, 14 May 2017 08:19:15 +0000 (UTC) (envelope-from joel.bertrand@systella.fr) Received: from rayleigh.systella.fr (rayleigh.systella.fr [213.41.150.218]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "rayleigh.systella.fr", Issuer "rayleigh.systella.fr" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id DCA5810A2; Sun, 14 May 2017 08:19:14 +0000 (UTC) (envelope-from joel.bertrand@systella.fr) Received: from [192.168.10.20] ([192.168.10.20]) (authenticated bits=0) by rayleigh.systella.fr (8.15.2/8.15.2/Debian-8) with ESMTPSA id v4E89Xch027378 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Sun, 14 May 2017 10:09:34 +0200 To: freebsd-ports@freebsd.org Cc: FreeBSD Hackers From: =?UTF-8?Q?BERTRAND_Jo=c3=abl?= Subject: Issue with pkg upgrade on diskless workstation Message-ID: Date: Sun, 14 May 2017 10:09:33 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:49.0) Gecko/20100101 Firefox/49.0 SeaMonkey/2.46 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.99.2 at rayleigh X-Virus-Status: Clean X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 May 2017 08:19:15 -0000 Hello, I'm trying to install a new software (xvnc) on a diskless workstation running FreeBSD 11. Server runs NetBSD 7.0.2 and this diskless workstation ran like a charm for a long time. pkg update was done (of course without error) and upgrade stalls (for several hours) : root@pythagore:~ # pkg upgrade Updating FreeBSD repository catalogue... FreeBSD repository is up to date. All repositories are up to date. Checking for upgrades (915 candidates): 2% pkg process takes 100% of CPU and there is no network activity. I haven't found any solution to achieve upgrade. Any idea ? Best regards, JB From owner-freebsd-hackers@freebsd.org Sun May 14 10:18: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 5DD0BD69CFD; Sun, 14 May 2017 10:18:17 +0000 (UTC) (envelope-from joel.bertrand@systella.fr) Received: from rayleigh.systella.fr (rayleigh.systella.fr [213.41.150.218]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "rayleigh.systella.fr", Issuer "rayleigh.systella.fr" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 23D2FB2B; Sun, 14 May 2017 10:18:16 +0000 (UTC) (envelope-from joel.bertrand@systella.fr) Received: from [192.168.10.20] ([192.168.10.20]) (authenticated bits=0) by rayleigh.systella.fr (8.15.2/8.15.2/Debian-8) with ESMTPSA id v4EAI0pN004000 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Sun, 14 May 2017 12:18:01 +0200 Subject: Re: Issue with pkg upgrade on diskless workstation To: Mark Linimon Cc: freebsd-ports@freebsd.org, FreeBSD Hackers References: <20170514082046.GA15092@lonesome.com> From: =?UTF-8?Q?BERTRAND_Jo=c3=abl?= Message-ID: Date: Sun, 14 May 2017 12:18:00 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:49.0) Gecko/20100101 Firefox/49.0 SeaMonkey/2.46 MIME-Version: 1.0 In-Reply-To: <20170514082046.GA15092@lonesome.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.99.2 at rayleigh X-Virus-Status: Clean X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 May 2017 10:18:17 -0000 Mark Linimon a crit : > I am running a powerpc64 machine diskless but only with some awful hacks. > I can make them available if need be, but I hope that someone else has a > better recommendation for you. > > mcl > Before the last pkg binary upgrade, this workstation ran fine. What kind of hack do you use ? Best regards, JB From owner-freebsd-hackers@freebsd.org Sun May 14 05:39: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 26497D6C31B for ; Sun, 14 May 2017 05:39:17 +0000 (UTC) (envelope-from jfs@jstimpfle.de) Received: from h1929017.stratoserver.net (jstimpfle.de [85.214.245.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E6D4B25C for ; Sun, 14 May 2017 05:39:16 +0000 (UTC) (envelope-from jfs@jstimpfle.de) Received: from jfs by h1929017.stratoserver.net with local (Exim 4.84_2) (envelope-from ) id 1d9lfg-0000E9-Os for freebsd-hackers@freebsd.org; Sun, 14 May 2017 07:02:20 +0200 Date: Sun, 14 May 2017 07:02:20 +0200 From: Jens Stimpfle To: freebsd-hackers@freebsd.org Subject: Improved Red-black tree implementation Message-ID: <20170514050220.GA768@jstimpfle.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) X-Mailman-Approved-At: Sun, 14 May 2017 11:17:41 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 May 2017 05:39:17 -0000 Hello, the BSD tree.h Red-black tree implementation has a design issue in that it doesn't share code between generated instances. Each instanciated tree costs about 3K of machine code (on amd64). Making multiple instances means increased pressure on the instruction cache (often 64K these days). In the last weeks I've designed a very efficient implementation that shares most of the machine code between all instances. There are macros for type safety equivalent to tree.h's, but they are only thin wrappers around the generic code. The implementation is about 15% faster than tree.h on my benchmark. It is quite similar in overall design (e.g. intrusively linked, no memory allocation). A notable difference is that color information is stored in the low child pointer bits, which might trouble some people, but it saves memory. It includes a shim for the tree.h API. A few touches are still missing, but it can probably work as drop-in replacement for most client code. Furthermore it allows for more flexible usage, for example search functions that receive additional context besides a search key. The code is currently at https://github.com/jstimpfle/sil/tree/master/rb3ptr Could FreeBSD profit from this improved implementation? I can adapt future development to simplify integration into the tree. Jens Stimpfle From owner-freebsd-hackers@freebsd.org Sun May 14 08:20:49 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 3BD93D6CA51; Sun, 14 May 2017 08:20:49 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (mail.soaustin.net [192.108.105.60]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.soaustin.net", Issuer "StartCom Class 2 IV Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 252761316; Sun, 14 May 2017 08:20:48 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from lonesome.com (bones.soaustin.net [192.108.105.22]) by mail.soaustin.net (Postfix) with ESMTPSA id BA70912CA; Sun, 14 May 2017 03:20:47 -0500 (CDT) Date: Sun, 14 May 2017 03:20:46 -0500 From: Mark Linimon To: BERTRAND =?iso-8859-1?Q?Jo=EBl?= Cc: freebsd-ports@freebsd.org, FreeBSD Hackers Subject: Re: Issue with pkg upgrade on diskless workstation Message-ID: <20170514082046.GA15092@lonesome.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Mailman-Approved-At: Sun, 14 May 2017 11:30:12 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 May 2017 08:20:49 -0000 I am running a powerpc64 machine diskless but only with some awful hacks. I can make them available if need be, but I hope that someone else has a better recommendation for you. mcl From owner-freebsd-hackers@freebsd.org Sun May 14 20:23: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 57263D6D671 for ; Sun, 14 May 2017 20:23:17 +0000 (UTC) (envelope-from pagx13@yahoo.gr) Received: from nm17-vm7.bullet.mail.ir2.yahoo.com (nm17-vm7.bullet.mail.ir2.yahoo.com [212.82.96.222]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C9179212 for ; Sun, 14 May 2017 20:23:16 +0000 (UTC) (envelope-from pagx13@yahoo.gr) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.gr; s=s2048; t=1494793283; bh=ygbUrlLG12T5jlnqEPxEnk+0n4S3lVjsN+J5Uw9t8BQ=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From:Subject; b=UDWwyo35k5PxsC72jCNu1/pZVBTj3848xtaDw21/OdrZWzBxT+165IwHG+VVwRg9kbRrsnVw17oGhh8ROZVWkHiaOHKhPWMw2iWwbCh0IHhqCsk4EM/eoHgA6n5tz3/byIyznR0l5yOj8feLAv+lkRuwhhtSatyVSEhiDvUPjphuBVMw+As/SwfTxUtIYF+CjoFHlmtqGH2VcKU9Cz9ERj8g2D+or0ud1W+GS/8y3fdMU7VvyAkznK1J4ANd18w1QRdiRk9aTwFr5W7ZHoZGAGLtuINjkw5B7HM+coyPDqT3cGKGoo2v753NI7yWgJacIpDfhHUHvQ15gfnWa4QLrA== Received: from [212.82.98.124] by nm17.bullet.mail.ir2.yahoo.com with NNFMP; 14 May 2017 20:21:23 -0000 Received: from [46.228.39.89] by tm17.bullet.mail.ir2.yahoo.com with NNFMP; 14 May 2017 20:21:23 -0000 Received: from [127.0.0.1] by smtp126.mail.ir2.yahoo.com with NNFMP; 14 May 2017 20:21:23 -0000 X-Yahoo-Newman-Id: 227654.15026.bm@smtp126.mail.ir2.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: uFlCbjYVM1nJoXgN.pH4GXjMWaokvvzue1u04H13BSfAeiP VJietc85MCgUSzoAO05je.MPy3GLzOADQ7RGN3zTGlwaNDLV08pZO98R6nOo i9PL4Mb0wud4AJUErd7o2idJWAfxCaccJqB4VGcMaT.eUKfQ7SDhFLCvsGuz PdL9ncqtUAZxuzcYoRPO.0bCthN07a7.A2JWnyX5f0h60ZGQR1wIeH6_uIyT FRXqP7yw.4uplupYNgVNWctUl_NRCW9pF1z00w5iCwMdV3WFNolF8N1.qrfk 5rDDWQZlEV05WnBXt5Z4sPPHY5SJn9G7Vf.pCRAiuez_R6U4dUNqSKlvNKCa .z1ZAGtVIKdgepb7gsm4HVfdbGT8l2ZcPvfoT7Okhz6UJrPvklSy3eAMj0PY XpF1Efy6b8rNfs4lTkEU_Zz_TdCwQIc5RkSMncbY8ru4oRKCJZE44Lw4mPWP m2XwC84NOC0Cx37rF2OnXsii5.OajhabQejLR7wtJEZPRTZEDTXiyCF2nYez .ZrPg9GTIIi5tN.NI1vFq8eGWDToDQVlt23362mUIPyIwmMnIu_tPAotPZMQ 2PPPfFFVlo0Otdw-- X-Yahoo-SMTP: Xarev0iswBArkyBOEr3Dxr_ZWQ-- Subject: Re: Announcing man-k.org To: Jov , Abhinav Upadhyay References: <20170513152446.1A7677A2AF@mollari.NetBSD.org> Cc: freebsd-hackers@freebsd.org From: Panagiotes Mousikides Message-ID: Date: Sun, 14 May 2017 20:21:22 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 May 2017 20:23:17 -0000 Hi Abhinav! Interesting tool, and it looks really nice, thanks! A suggestion, it would be nice to have a table of contents at the top of every man page, so that the reader can quickly jump to the desired section. Sort of like how Wikipedia and similar do it! I find myself often jumping from section to section when reading a manpage, so that feature would be great! All the best, Paggas Den 2017-05-13 kl. 15:58, skrev Jov: > It's a useful tool,thanks! > > 2017年5月13日 11:25 PM，"Abhinav Upadhyay" 写道： > >> Hi, >> >> My name is Abhinav Upadhyay, I am a NetBSD user and developer. I would >> like to >> introduce http://man-k.org - a web interface to NetBSD's apropos(1). It >> is a >> full text search tool for man pages, providing support for searching >> FreeBSD, >> NetBSD, OpenBSD, Linux and Posix man pages. >> >> Apart from full text search, the man pages have syntax highlighting (at >> least >> the mdoc(7) man pages have, see [1] for example). Also, the header >> includes in >> the man pages are hyperlinked to OpenGrok for looking up the header files >> (see [2] for an example). >> >> I have talked about it briefly at last year's EuroBSDCon and AsiaBSDCon in >> the >> context of applying machine learning to improve ranking in NetBSD's >> apropos(1). >> But it only had support for searching NetBSD man pages back then. >> >> I would like to invite you all to use it and let me know of any feedback or >> suggestions you might have to improve it. :-) >> >> [1]:http://man-k.org/man/FreeBSD-12.0-CURRENT/2/kevent >> [2]:http://man-k.org/man/FreeBSD-12.0-CURRENT/3/strtonum >> >> - >> Abhinav >> _______________________________________________ >> 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 Mon May 15 06:20: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 77822D6CC38 for ; Mon, 15 May 2017 06:20:44 +0000 (UTC) (envelope-from er.abhinav.upadhyay@gmail.com) Received: from mail-ua0-x22b.google.com (mail-ua0-x22b.google.com [IPv6:2607:f8b0:400c:c08::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 2BCC5185E for ; Mon, 15 May 2017 06:20:44 +0000 (UTC) (envelope-from er.abhinav.upadhyay@gmail.com) Received: by mail-ua0-x22b.google.com with SMTP id e28so72752479uah.0 for ; Sun, 14 May 2017 23:20:44 -0700 (PDT) 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; bh=KfMOVrenN5CTu8jxhjOuHmWRF5YjXe1hqZSq8m9gwBA=; b=J4mGA6pyY7h8SPaKACgWpxpK9MpL5my8rWy4gx6Z2yCIcrGXllATwxDLjKikFUTCHM R8aMaChFI3B9fUBb/IIF2XzPEIIuXs4aCtw7gV0b8ozTOhKe6/JvDkAzqB4l5GPuNx+m O6HynF/AZ1H3DOm4xc/VkYq96fXN8whdIe38R4x3ZGpsjIFXOwfrReVxL+cLx0Cl5kZz lcAON6+lTRXun2Z8WmtEofhND52TIAvXSIO525sd60imQoPYIDRCDpxd4Lobe93nRqHt bxfm49q190wphD/EX2EJPgBxqJLgOGnTB9Qbn/Rs/yIDiuA4P1kibzVqDku8Vwx12wSE w1Hw== 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; bh=KfMOVrenN5CTu8jxhjOuHmWRF5YjXe1hqZSq8m9gwBA=; b=OY1JijRXYfGfjF6xnNGrC2j3IzA3DY6h6hfhnHzA+jBoxM37TCcy8XZZwihsVRgYwY wXAdCepee9JRgjGIuho+FxBcjsaiCEp7kezd/dSOyprEV22Ep5WAxuLm9n2FOFGGDGXP O8RcSK4yFBNw+UOXzPOQBFLrL/gde2958/wqrjq3IVw5QCemmwYS64saqkMU5gjb+Yq5 GNDXiq6k9VpicV8sW4HUIpBYPHBFsVKXdwkDvVwC/S+PG9qSbPDgLtSOd/wNPw5FxsaX UyH2KDG5EbpigSmyPTlwDBC+XsXpkMczj0MA5jY9dCs6bOOsBYacyuz8vdKZEgp5MXQI wL2g== X-Gm-Message-State: AODbwcB1mbMtgWqNeKdMl38WQy0EYvzpc56UdDhq9Am10o4t8Bnyv9o6 yBWQQ/+6rxA7V5aepM/TpixVpvHidUpwhNA= X-Received: by 10.159.60.1 with SMTP id u1mr2152936uah.95.1494829242997; Sun, 14 May 2017 23:20:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.54.239 with HTTP; Sun, 14 May 2017 23:20:42 -0700 (PDT) In-Reply-To: <20170513152446.1A7677A2AF@mollari.NetBSD.org> References: <20170513152446.1A7677A2AF@mollari.NetBSD.org> From: Abhinav Upadhyay Date: Mon, 15 May 2017 11:50:42 +0530 Message-ID: Subject: Re: Announcing man-k.org To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 May 2017 06:20:44 -0000 On Sat, May 13, 2017 at 8:54 PM, Abhinav Upadhyay wrote: > Hi, > > My name is Abhinav Upadhyay, I am a NetBSD user and developer. I would like to > introduce http://man-k.org - a web interface to NetBSD's apropos(1). It is a > full text search tool for man pages, providing support for searching FreeBSD, > NetBSD, OpenBSD, Linux and Posix man pages. > > Apart from full text search, the man pages have syntax highlighting (at least > the mdoc(7) man pages have, see [1] for example). Also, the header includes in > the man pages are hyperlinked to OpenGrok for looking up the header files > (see [2] for an example). > > I have talked about it briefly at last year's EuroBSDCon and AsiaBSDCon in the > context of applying machine learning to improve ranking in NetBSD's apropos(1). > But it only had support for searching NetBSD man pages back then. > > I would like to invite you all to use it and let me know of any feedback or > suggestions you might have to improve it. :-) > > [1]:http://man-k.org/man/FreeBSD-12.0-CURRENT/2/kevent > [2]:http://man-k.org/man/FreeBSD-12.0-CURRENT/3/strtonum > While here, I would also like to note http://man-k.org/whatis - Which allows to do whatis(1) kind of queries across platforms. So, if you wanted to see which of the operating system releases ship with a given function, utility, or driver, you could use this. However, it is simply a whatis(1) query, so it only understands proper man page names. :-) The idea was suggested by Robert Elz (kre) on the NetBSD mailing list. - Abhinav From owner-freebsd-hackers@freebsd.org Mon May 15 06:25:37 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 889E2D6CF05 for ; Mon, 15 May 2017 06:25:37 +0000 (UTC) (envelope-from er.abhinav.upadhyay@gmail.com) Received: from mail-vk0-x22c.google.com (mail-vk0-x22c.google.com [IPv6:2607:f8b0:400c:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3D2EC1C3E for ; Mon, 15 May 2017 06:25:37 +0000 (UTC) (envelope-from er.abhinav.upadhyay@gmail.com) Received: by mail-vk0-x22c.google.com with SMTP id x71so42069370vkd.0 for ; Sun, 14 May 2017 23:25:37 -0700 (PDT) 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=hSDgTqre/X1nTI33u+Yu8741hl1q5mQzPT7CcA/27e8=; b=o4+FokQM5rxI8Y84hmwoQ+nO6V9tJ+Jw8pOVH8MNXGFoiDdHfi3NuIonNSNDDifA4M Xyndpiv6PiaT9d1yhlesq4447HXyWHtXMeuqVZbBSI1wsXDWaAfR8g5hSQQlsVmweMVa Ah2N6mCd0vYUBc9dWu7dtv+Mohk7mLjzsmYyi+hinecswNP/hMUvdz28PNLmWpTBhqj5 tShEjU4DXGPB7FJGHgx5cO3sHXYq1B0InbSrp0fYIWFvjKPJVjZuzJkjriGqHzRo6Ak0 k+qbhVHkJyuotimHNk+Ksn+Emk+zCOKH53m2eY5qqlshLMp2GWpVP+5hJSO0SaDG2A0P ai9g== 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=hSDgTqre/X1nTI33u+Yu8741hl1q5mQzPT7CcA/27e8=; b=g+9ZdW7q7ddzgXMZzCMk3b7TIPWDAodqi/TirHxO6XpnNMc36BuaR4v2opZIFgcmy0 Zkudv71Lj2UAk5Okb1q5lHqDiaXPS5HjwT6AZzXmrS1/mAwdhrnefRDD1+jYAIq4SQ0Z MCOLhW0K5722QXqGA0Lm1U9xYT4vUPJrHqJG7+A0mOfqjL3cHUOxa3VzBTY1KluteqX5 /0441afBX1gcAq+/R1YQrAG2F+SktI8yqydumT5reRxmlYPH+rjQxrrRXkraxolM7UwZ ejyoXS29tddj/fGMqYbRaPDDrZvGpAZXOICIojrP6ek1978XriOWlE11qHayEE5NJm+V ZIEQ== X-Gm-Message-State: AODbwcBo0dq7xuQ3XzPPgZdQgGX6FsQTXQHtfu4v5vM9STyOIvdhqqRZ 06CHxfDfbPw5bgKcCcO8m4n5drcHVA== X-Received: by 10.31.69.138 with SMTP id s132mr2079276vka.97.1494829536328; Sun, 14 May 2017 23:25:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.54.239 with HTTP; Sun, 14 May 2017 23:25:35 -0700 (PDT) In-Reply-To: References: <20170513152446.1A7677A2AF@mollari.NetBSD.org> From: Abhinav Upadhyay Date: Mon, 15 May 2017 11:55:35 +0530 Message-ID: Subject: Re: Announcing man-k.org To: Panagiotes Mousikides Cc: Jov , freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 May 2017 06:25:37 -0000 On Mon, May 15, 2017 at 1:51 AM, Panagiotes Mousikides via freebsd-hackers wrote: > Hi Abhinav! > > Interesting tool, and it looks really nice, thanks! Thanks :) > A suggestion, it would be nice to have a table of contents at the top of > every man page, so that the reader can quickly jump to the desired section. > Sort of like how Wikipedia and similar do it! I find myself often jumping > from section to section when reading a manpage, so that feature would be > great! I am using mandoc(1) to generate the HTML pages. It is not straightforward to generate a ToC with it and probably would require some non-trivial hacking of its html generator code to achieve this, but it would be interesting work. I will keep note of it in my list of things to do, thanks for the suggestion, I appreciate it :-) - Abhinav From owner-freebsd-hackers@freebsd.org Mon May 15 16:34:12 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 6D99BD6ECB8 for ; Mon, 15 May 2017 16:34:12 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 23064137F for ; Mon, 15 May 2017 16:34:12 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-yw0-x22f.google.com with SMTP id l14so40427383ywk.1 for ; Mon, 15 May 2017 09:34:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=lGs62v///MRtIqoGt8fKJqVH59M+dNJsKUM6Ff9x4YI=; b=BUL9NeFsGMlmHTUGrzKJZORdf4bQEGWUZ0znI/AUbE+ToKWxAkq0kEDq/zu8b5kboI ZC34nKj5e3HeDWquvxJ3dlVYV1WO94oUfZ8PxaGpDNjuksMdk3jeY5wMwovvcp5bD++y AAi+e4n/jX8GuBqCGl1MlMbCGHZGhcPKhP//H5Pq794SUUbHPfx5px1kKaJ4kbi9nACW mbzocPhywArVZaqhRKlutKdm8bAxlIY4NpfsnVyy0bBj7hh2DI34DegWkh0fzqvIn6Oo DEQ9S5I2s2r7YItcp2pkfGsVcNs9QKF0UBEM6rGtdk+58OQQjy505FoLRN/YiarRAWmG t80Q== 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=lGs62v///MRtIqoGt8fKJqVH59M+dNJsKUM6Ff9x4YI=; b=QVIEV1aFEl8txFtAlt9LBvUAVw2biDb4p++hhZJTseS0js6x/xaYLvJnROlHEUpc4q cueZkYV09HSwdXRBC4Obt9DzMWRtbDuh6ma9bDXBlbTY8/0xsVjzZEm7b6SeluXshV8y pGzOJxeZV0tzQSWcqPO0zXNPwKJHfK69qu59L1QErkqSfD4Ujli7tkm0OhrRYEAVWCCt 6zHb9GTozcyLYktSkB8gKrLpwziMyu33/0DoxfD4f3gqRz/9q9auEBM7kqD8krcAsJbY N0xYgRxub7VvhVNQ1noELwDfs3TjrAba9RVDNMPKy/ALcKcZR4ed/YjMdm8f2I2FkFm5 X6nQ== X-Gm-Message-State: AODbwcDCFtAHd9iJ0z9lL32m6y4CgxcXvur2QVubuGV51/rEeLixa1WI ivkVyP7zzfJYEO9grQ1wtUZEmjrMHA== X-Received: by 10.13.228.199 with SMTP id n190mr5656078ywe.279.1494866051215; Mon, 15 May 2017 09:34:11 -0700 (PDT) MIME-Version: 1.0 Sender: asomers@gmail.com Received: by 10.129.20.214 with HTTP; Mon, 15 May 2017 09:34:10 -0700 (PDT) In-Reply-To: <20170514050220.GA768@jstimpfle.de> References: <20170514050220.GA768@jstimpfle.de> From: Alan Somers Date: Mon, 15 May 2017 10:34:10 -0600 X-Google-Sender-Auth: qa3NHFxMh4YddxKqfo3BlehKgUU Message-ID: Subject: Re: Improved Red-black tree implementation To: Jens Stimpfle Cc: "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 May 2017 16:34:12 -0000 On Sat, May 13, 2017 at 11:02 PM, Jens Stimpfle wrote: > Hello, > > the BSD tree.h Red-black tree implementation has a design issue in that > it doesn't share code between generated instances. Each instanciated > tree costs about 3K of machine code (on amd64). Making multiple > instances means increased pressure on the instruction cache (often 64K > these days). > > In the last weeks I've designed a very efficient implementation that > shares most of the machine code between all instances. There are macros > for type safety equivalent to tree.h's, but they are only thin wrappers > around the generic code. The implementation is about 15% faster than > tree.h on my benchmark. > > It is quite similar in overall design (e.g. intrusively linked, no > memory allocation). A notable difference is that color information is > stored in the low child pointer bits, which might trouble some people, > but it saves memory. It includes a shim for the tree.h API. A few > touches are still missing, but it can probably work as drop-in > replacement for most client code. > > Furthermore it allows for more flexible usage, for example search > functions that receive additional context besides a search key. > > The code is currently at > https://github.com/jstimpfle/sil/tree/master/rb3ptr > > Could FreeBSD profit from this improved implementation? I can adapt > future development to simplify integration into the tree. > > Jens Stimpfle Nice work, Jens. This certainly sounds like an improvement. A few questions: 1) Are there any automated tests? I would definitely want robust coverage for something this complicated. 2) FreeBSD can't rely on any Python code during the build. Does gen-macros.py need to be run on every build? Or is it more like autoreconf, something that gets run when a developer modifies the RB code, and then checks in its output? 3) Do you know of any examples of programs that use multiple instances of RB trees? -Alan From owner-freebsd-hackers@freebsd.org Mon May 15 20:10: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 73A45D6E7F6 for ; Mon, 15 May 2017 20:10:44 +0000 (UTC) (envelope-from jfs@jstimpfle.de) Received: from h1929017.stratoserver.net (jstimpfle.de [85.214.245.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3E4A61ADD for ; Mon, 15 May 2017 20:10:43 +0000 (UTC) (envelope-from jfs@jstimpfle.de) Received: from jfs by h1929017.stratoserver.net with local (Exim 4.84_2) (envelope-from ) id 1dAMKB-0001sk-1W for freebsd-hackers@freebsd.org; Mon, 15 May 2017 22:10:35 +0200 Date: Mon, 15 May 2017 22:10:35 +0200 From: Jens Stimpfle To: freebsd-hackers@freebsd.org Subject: Re: Improved Red-black tree implementation Message-ID: <20170515201035.GA6853@jstimpfle.de> References: <20170514050220.GA768@jstimpfle.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Mailman-Approved-At: Mon, 15 May 2017 21:25:38 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 May 2017 20:10:44 -0000 On Mon, May 15, 2017 at 10:34:10AM -0600, Alan Somers wrote: > Nice work, Jens. This certainly sounds like an improvement. A few questions: > 1) Are there any automated tests? I would definitely want robust > coverage for something this complicated. So far there is only the benchmark code, one directory level up. If there's use for it that would be motivation for me to work on packaging, also including automated tests and documentation. > 2) FreeBSD can't rely on any Python code during the build. Does > gen-macros.py need to be run on every build? Or is it more like > autoreconf, something that gets run when a developer modifies the RB > code, and then checks in its output? More like autoreconf. The output of gen-macros.py is something like tree.h. > 3) Do you know of any examples of programs that use multiple instances > of RB trees? Tmux has 14 instances. I have no idea if the saved code matters in any practical application. It could be rare that more than two instances or so are active at the same time *and* the size of the client code is not dominating. But if anything, code sharing is "the right thing". Digression: I figure most algorithmic implementations could be generic. Even if many data structures need a "stride" parameter. Are there case where it's clearly better to duplicate code for some data structure whose instances are only differing by integer parameters? For functions parameters, there is the famous example of std::sort being faster than qsort, but that must be about the most extreme one: On flat arrays function call overhead dominates cache miss overhead to the point where it sometimes makes sense to inline the function call. Jens From owner-freebsd-hackers@freebsd.org Tue May 16 03:28:40 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 C8C6DD6F239 for ; Tue, 16 May 2017 03:28:40 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 91F91CDE for ; Tue, 16 May 2017 03:28:40 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-it0-x22f.google.com with SMTP id o5so54884972ith.1 for ; Mon, 15 May 2017 20:28:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=/Vh3AvinqzIDdsRLJW9syzBm8OEswB8fM35eETVqH24=; b=b5tdYYzCsBr8eM1QI4wEpr3y9Zn2aK/SbKurr2lcuppnVbYJDiUDOfy0oGSmOf5dVX ILH4L00ZZem8ocmGPG/bU4biKHkw+StSZ2BcMkRnppiJdtknKslbA3hVvG5SdhJPiByD IP0neQGWHFQNkxF1lEN9GdCX5LUh7xohTbNG5a+S/cvJIQRoQEIEAHGDTLxSWZYLG3cc l8xcN+zCj/wVzTgM0YBGhWnmaccNrkhA09AoQ7acWnA5jl6Y3EoZ0eUA9drEpAfMxH9w FqvS1yZZ2NbhuSmgQSEJNSemV642DRsnQXI5pWbtksQoUm/Og9+z0UZ3Cg3u97bcWvSC TbqQ== 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=/Vh3AvinqzIDdsRLJW9syzBm8OEswB8fM35eETVqH24=; b=IlkKak7GqpnTgWfnW+Yw+LOQM4i5mXTrZHvorTTKZ4SI9ChXDZjZfjhdjPbZ3jRfc2 PpLhzzKcip5AAAiZzQq9NEFsBTMX9y4bBxpukBPdOsHQCzS5O6JZ7UxXQcSs8EpDSzGL E0CCG73GM8Qs+I4nS+kF8GD3P/bcr7SwPc88I+C8WruTIgeeJ5mo5POcxRUB2QOLXQfu mxLi2P2bWOQspuOhAwE8zIUtFQzw36H35ON89KiufpeQLq8YIUc1f9XOXAKwyZk+p6SO MPLUypbcZJEPtHeGLqFRjofCWq3tZnE+yJlCZZJxcjgoScHGnyD7IHG76gp3bosKsDzJ 7D5A== X-Gm-Message-State: AODbwcCrgQyYinwwnfTorWngN4uhFKaayW9POeiTI2rHtpAuTc7Zxbeh xM905lgYKto/aPAwXbUjqGOcyxzB6EciB3c= X-Received: by 10.36.43.146 with SMTP id h140mr8610526ita.7.1494905319989; Mon, 15 May 2017 20:28:39 -0700 (PDT) MIME-Version: 1.0 Sender: carpeddiem@gmail.com Received: by 10.107.169.201 with HTTP; Mon, 15 May 2017 20:28:19 -0700 (PDT) In-Reply-To: <20170512231658.GA82997@troutmask.apl.washington.edu> References: <20170512212518.GA82236@troutmask.apl.washington.edu> <1494624672.59865.74.camel@freebsd.org> <20170512213756.GB82390@troutmask.apl.washington.edu> <20170512231658.GA82997@troutmask.apl.washington.edu> From: Ed Maste Date: Mon, 15 May 2017 23:28:19 -0400 X-Google-Sender-Auth: vsgLSPE1Z0QepOM4Rmshm75kjv4 Message-ID: Subject: Re: nm(1) -- what is 'r'? To: Steve Kargl Cc: "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 May 2017 03:28:40 -0000 On 12 May 2017 at 19:16, Steve Kargl wrote: > > It should probably go upstream to Elftoolchain. I, however, did not > find a reporting mechanism. ELF Tool Chain's bug reports are here: https://sourceforge.net/p/elftoolchain/tickets/ From owner-freebsd-hackers@freebsd.org Tue May 16 04:48: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 EB5BED6FFE9; Tue, 16 May 2017 04:48:03 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (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 2B4211FC4; Tue, 16 May 2017 04:48:02 +0000 (UTC) (envelope-from kaduk@mit.edu) X-AuditID: 12074425-507ff700000001c7-56-591a834c83a1 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-8.mit.edu (Symantec Messaging Gateway) with SMTP id 16.A8.00455.C438A195; Tue, 16 May 2017 00:42:52 -0400 (EDT) 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 v4G4goDV021949; Tue, 16 May 2017 00:42:50 -0400 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 v4G4gjbp022836 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 16 May 2017 00:42:48 -0400 Date: Mon, 15 May 2017 23:42:45 -0500 From: Benjamin Kaduk To: freebsd-hackers@FreeBSD.org Cc: freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org Subject: FreeBSD Quarterly Status Report - First Quarter 2017 Message-ID: <20170516044244.GD39245@kduck.kaduk.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="A6N2fC+uXW/VQSAv" Content-Disposition: inline User-Agent: Mutt/1.7.1 (2016-10-04) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrKKsWRmVeSWpSXmKPExsUixCmqrevTLBVp8POpiMWua6fZLea8+cBk sX3zP0aLw81CDiweMz7NZwlgjOKySUnNySxLLdK3S+DK2NL+hKlgwXumirV35BsY18xj6mLk 5JAQMJE48v85YxcjF4eQwGImia4rB9khnI2MEuvWvWSBcK4ySfROXsIK0sIioCpxaOdMZhCb TUBNYv2Ka2C2iIC8xL6m9+wgNrOAtcS/B41gcWEBW4nPU2eD9fICrbt1pIUdwhaUODnzCQtE fZlEc+taIJsDyJaWWP6PAyQsKqAs8ffwPZYJjHyzkHTMQtIxC6EDIqwu8WfeJWYMYW2JZQtf M0PYtkCPvWdZwMi+ilE2JbdKNzcxM6c4NVm3ODkxLy+1SNdCLzezRC81pXQTIyi82V1UdzDO +et1iFGAg1GJh3fFCslIIdbEsuLK3EOMkhxMSqK8adVSkUJ8SfkplRmJxRnxRaU5qcWHGFWA dj3asPoCoxRLXn5eqpIIb50JUB1vSmJlVWpRPkyZNAeLkjivuEZjhJBAemJJanZqakFqEUxW hoNDSYJ3QyNQo2BRanpqRVpmTglCmomD8xCjBAcP0PDiBpDhxQWJucWZ6RD5U4zGHO+WfnjP xNF15s97JiGwO6TEeWeCjBMAKc0ozYObBkpdEtn7a14xigM9Ksy7uAmoigeY9uDmvQJaxQS0 KuylOMiqkkSElFQDo/3BIM76SQf0Z86OCNl9ySjpaPXaR3ckz2g8OuSt1XzMaOeR+q9b+s9p vnoz5WXyvGN7vkuEnEu2W5Xovt5tr1IRZ1Rl+RHhVd4Bqgu0Hi9c6MURdOx/ZEtGjEfR04tT uDbGy00WLDLiXrCq/Oi8zbIpShn94VEPHjs+XnVaoL3g2Qqjl6kHEpRYijMSDbWYi4oTAVsv EUM4AwAA X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 May 2017 04:48:04 -0000 --A6N2fC+uXW/VQSAv Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable FreeBSD Project Quarterly Status Report - 1st Quarter 2017 While a few of these projects indicate they are a "plan B" or an "attempt III", many are still hewing to their original plans, and all have produced impressive results. Please enjoy this vibrant collection of reports, covering the first quarter of 2017. --Benjamin Kaduk __________________________________________________________________ The deadline for submissions covering the period from April to June 2017 is July 7, 2017. __________________________________________________________________ FreeBSD Team Reports * The FreeBSD Core Team * The FreeBSD Foundation * The FreeBSD Ports Collection * The FreeBSD Release Engineering Team Projects * Ceph on FreeBSD * OpenBSM * Porting Software to CloudABI: Sandboxed Bitcoin! * Support for eMMC Flash and Faster SD Card Modes * TrustedBSD Kernel * FreeBSD on Hyper-V and Azure * Intel 10G and 40G Network Driver Updates * Linuxulator * MMC Stack Using the CAM Framework * pNFS Server Plan B Architectures * 64-bit PowerPC Book-E Support * FreeBSD on Marvell Armada38x * FreeBSD/s390x Attempt III Ports * MySQL * Rust Documentation * The FreeBSD Dutch Documentation Project __________________________________________________________________ FreeBSD Team Reports The FreeBSD Core Team Contact: FreeBSD Core Team Core's primary function is to ensure the long-term viability of the FreeBSD project. A very large part of that is to ensure that the interactions between developers remain cordial, and consequently that the project appears welcoming to newcomers. Normally, most of Core's activities around this are done in private -- a quiet word in the right ear, some discrete peacemaking, occasional reading of the riot act. Most of the time, this is all that is necessary. Unfortunately, this quarter we had an instance where such private measures failed to achieve the desired result, and we ended up ejecting a developer. This developer is an extremely talented programmer and has made significant contributions to the Ports Collection. Despite this, portmgr found him to be sufficiently disruptive and abrasive that in their judgement, the project was better off overall to sever his connection to itself, and core backed them up in that. We are sorry that events came to this sad conclusion, but we remain convinced that this was a necessary step to safeguard the character of our community. In a more positive light, Core has been working on a proposal to recognise notable contributors to the FreeBSD project who are not (or perhaps not yet) suitable to be put forward as new committers. In addition to the usual routes of recognising people that write numbers of good bug reports or that supply patches or that volunteer to maintain ports, this will also allow recognition of people who contribute by such things as organising FreeBSD events or who promote FreeBSD through social media. A formal announcement of Core's proposal is imminent. During January, the core secretary held an exercise to contact all source committers who had been inactive for more than 18 months and persuade them to hand in their commit bits if they were not planning to resume working on FreeBSD in the near future. This is meant to be a routine function -- the "grim reaper" -- that aims to keep the list of people with the ability to commit pretty much in synchrony with the list of people that are actively committing. The regular process had fallen out of activity several years ago, and we needed to clear the decks before restarting. Ultimately, this resulted in some 20 developers-emeritus handing in their commit bits. No new commit bits were awarded during this quarter. Core is also taking soundings on producing a 10.4-RELEASE. This is not in the current plan, but a number of developers and important FreeBSD users would be keen to see it happen, given some of the work that has gone into the stable/10 branch since 10.3-RELEASE. On the other hand, this would represent an additional support burden for the Security Team, including maintaining versions of software that have been declared obsolete upstream, in particular OpenSSL. As an even-numbered release, 10.4-RELEASE would have a "normal" rather than an "extended" lifetime which means it should not result in extending the support lifetime of the stable/10 branch. In other news, Core arranged for the old and largely inactive marketing@FreeBSD.org mailing list to be wound up, and for any remaining activities to be transferred to the FreeBSD Foundation. Core also asked clusteradm to turn off Internet-wide access to the finger server on freefall.freebsd.org. Many developers have included details such as phone numbers into the GECOS field of their FreeBSD password database entries, and these would be revealed by the finger server -- details which are nowadays generally felt inadvisable to expose publicly. finger is still available internally within freefall.freebsd.org. Core recommends that GECOS data is limited to just your full name, and we have updated the standard "new committer" e-mail template to reflect that. Core is looking for new volunteers to help out with several of the teams that manage various aspects of the project. In particular, Postmaster and the Security Team are in need of new blood. Recruiting for a new member of the Security Team is well under way, but anyone interested in joining any of the teams is encouraged to make themselves known either to Core or directly to the teams concerned. __________________________________________________________________ The FreeBSD Foundation Links FreeBSD Foundation Website URL: https://www.FreeBSDFoundation.org/ Quarterly Newsletter URL: https://www.FreeBSDfoundation.org/wp-content/uploads/2017/03/FreeB= SD-Foundation-Q1-2017-Update.pdf 2017 Storage Summit URL: https://wiki.FreeBSD.org/201702StorageSummit 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; 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. Our work is 100% funded by your donations. We kicked off the new year with some large contributions from Intel and NetApp, to help us raise over $400,000 last quarter! We engaged in discussions with new and old commercial users to help facilitate collaboration, explain how the Project works, and to ask for financial contributions to help us keep FreeBSD the innovative, secure, and reliable operating system they depend on. Please consider making a donation today! https://www.FreeBSDfoundation.org/donate/. 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. Our contributions also include funding separate project grants like the arm64 port, blacklistd access control daemon, and integration of VIMAGE support, to make sure FreeBSD remains a viable solution for research, education, computing, products and more. This quarter's project development highlights include: * 168 commits sponsored by the FreeBSD Foundation in the src tree (base system) development branch, across three staff members and four grant recipients/other developers. * Multiple funded grants, including the cfumass project, now committed to FreeBSD-HEAD, and improvements to the blacklistd daemon and FreeBSD/arm64 port. * Staff contributions including improvements to toolchain and build tool components, run time libraries, arm64, mips64 and 32- and 64-bit x86 architectures, release image build tooling, packaged base, and VM subsystem bug fixes. * Significant progress on the 64-bit inode project, which is nearly ready for commit. 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 to use FreeBSD or contribute to the Project easier; and attending and getting other FreeBSD contributors to volunteer to run FreeBSD events, staff FreeBSD tables, and give FreeBSD presentations. Some of the highlights of our advocacy and education work over the last quarter: * Promoted FreeBSD at: FOSDEM, SCALE, AsiaBSDcon, and FOSSASIA * Promoted BSDCan, SCALE, USENIX LISA, vBSDcon and EuroBSDcon Calls for Participation * Promoted Google Summer of Code participation on social media and created a flyer for people to post at their universities * Published a New Faces of FreeBSD Story: Joseph Kong * Set up a Marketing Partnership with the USENIX Association and SNIA * Published and Promoted the Jan/Feb 2017 issue of the FreeBSD Journal: https://www.FreeBSDfoundation.org/journal/ * Published monthly Development Projects Updates on our blog * Secured a FreeBSD table at OSCON and promoted available discounts Conferences and Events 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 about FreeBSD, to increase the use of FreeBSD in different applications, and to recruit more contributors to the Project. We also sponsored and/or attended the following events last quarter: * FOSDEM FreeBSD developer summit (sponsor) * AsiaBSDCon -- Tokyo, Japan (sponsor) * Organized and ran the FreeBSD Storage Summit in Santa Clara, CA * Board member Philip Paeps gave a FreeBSD presentation at FOSSASIA * Attended FOSSASIA, FOSDEM, and SCALE 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. Some highlights from last quarter include: * Continued the production of weekly development snapshots for the 12-CURRENT, 11-STABLE, and 10-STABLE branches. * Published the initial FreeBSD 11.1-RELEASE schedule to the Project website. Legal/FreeBSD IP The Foundation owns the FreeBSD trademarks, and it is our responsibility to protect them. We continued to review requests and grant permission to use the trademarks. Many more details about how we supported FreeBSD last quarter can be found in our Q1 newsletter! __________________________________________________________________ The FreeBSD 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 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=C3=A9 Ladan Contact: FreeBSD Ports Management Team The number of ports is currently just 500 short of 30,000. The current number of PRs is close to 2,400, of which 620 are unassigned. The last quarter saw 6656 commits from 167 comitters. Both the number of ports and the number of unassigned PRs have increased in the last quarter. In the last quarter, we welcomed 7 new committers: Eugene Grosbein (eugen), Johannes Dieterich (jmd), Larry Rosenman (ler), Mahdi Mokhtari (mmohki), Matthew Rezny (rezny), Tobias Kortkamp (tobik), and Vladimir Kondratyev (wulf). dumbbell@ was already a src committer and got an extension for the Ports Tree. We also welcomed back krion@ and miwi@. We took 6 bits in for safe-keeping: itetcu@, leeym@, mva@, olivierd@, pgollucci@, and sanpei@. There were no changes to the membership of portmgr. antoine@ worked on USES=3Dsamba to prepare for the removal of the long-outdated Samba 3.6 ports and replace them with modern versions. The new default versions are: FreePascal 3.0.2, Ruby 2.3, and Samba 4.4. A new variable USE_LOCALE was created to add the LANG and LC_ALL environment variables to all builds. Out-of-tree patches can now be added with the new EXTRA_PATCH_TREE variable. The error messages for invalid OPTIONS_SINGLE options were improved. Some of the major port updates last quarter were: pkg 1.10.1, linux c6_64, Firefox 52.0.2, Chromium 57.0.2987.110, GCC 4.9.4, Gnome 3.18.0, Xorg 1.18.4, Qt 4.8.7 and 5.7.1, and PHP 7.1. antoine@ ran 31 exp-runs to test version updates and under-the-hood changes. Open tasks: 1. The number of unassigned and open PRs is still growing, so if you have some spare time, please close some of those. __________________________________________________________________ The FreeBSD Release Engineering Team Links FreeBSD 11.1-RELEASE Schedule URL: https://www.freebsd.org/releases/11.1R/schedule.html FreeBSD development Snapshots URL: http://ftp.freebsd.org/pub/FreeBSD/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 producing weekly development snapshots for the 12-CURRENT, 11-STABLE, and 10-STABLE branches. In addition, the FreeBSD 11.1-RELEASE schedule was added to the Project website. Please note, however, the schedule on the website is still subject to change. This project was sponsored by The FreeBSD Foundation. __________________________________________________________________ Projects Ceph on FreeBSD Links Ceph Main Site URL: http://ceph.com Main Repository URL: https://github.com/ceph/ceph My FreeBSD Fork URL: https://github.com/wjwithagen/ceph Contact: Willem Jan Withagen Ceph is a distributed object store and file system designed to provide excellent performance, reliability and scalability. * Object Storage Ceph provides seamless access to objects using native language bindings or radosgw, a REST interface that is compatible with applications written for S3 and Swift. * Block Storage Ceph's RADOS Block Device (RBD) provides access to block device images that are striped and replicated across the entire storage cluster. * File System Ceph provides a POSIX-compliant network file system that aims for high performance, large data storage, and maximum compatibility with legacy applications. I started looking into Ceph because the HAST solution with CARP and ggate did not really do what I was looking for. But I aim to run a Ceph storage cluster of storage nodes that are running ZFS. User stations would be running bhyve on RBD disks that are stored in Ceph. Compiling for FreeBSD will now build most of the tools available in Ceph. Notable progress since the last report: * The most important change is that a port has been submitted: net/ceph-devel. However, it does not yet contain ceph-fuse. * Regular updates to the ceph-devel port are expected, with the next one coming in April. * ceph-fuse works, allowing one to mount a CephFS filesystem on a FreeBSD system and perform normal operations. * ceph-disk prepare and activate work for FileStore on ZFS, allowing for easy creation of OSDs. * RBD is actually buildable and can be used to manage RADOS BLOCK DEVICEs. * Most of the awkward dependencies on Linux-isms are deleted -- only /bin/bash is here to stay. To get things running on a FreeBSD system, run pkg install net/ceph-devel or clone https://github.com/wjwithagen/ceph and build manually by running ./do_freebsd.sh in the checkout root. Parts not (yet) included: * KRBD: Kernel Rados Block Devices are implemented in the Linux kernel, but not yet in the FreeBSD kernel. It is possible that ggated could be used as a template, since it does similar things, just between two disks. It also has a userspace counterpart, which could ease development. * BlueStore: FreeBSD and Linux have different AIO APIs, and that incompatibility needs to resolved somehow. Additionally, there is discussion in FreeBSD about aio_cancel not working for all devicetypes. * CephFS as native filesystem: though ceph-fuse works, it can be advantageous to have an in-kernel implementation for heavy workloads. Cython tries to access an internal field in struct dirent, which does not compile. Open tasks: 1. Run integration tests to see if the FreeBSD daemons will work with a Linux Ceph platform. 2. Compile and test the userspace RBD (Rados Block Device). This currently works but testing has been limitted. 3. Investigate and see if an in-kernel RBD device could be developed akin to ggate. 4. Investigate the keystore, which can be embedded in the kernel on Linux and currently prevents building Cephfs and some other parts. The first question is whether it is really required, or only KRBD requires it. 5. Scheduler information is not used at the moment, because the schedulers work rather differently between Linux and FreeBSD. But at a certain point in time, this will need some attention (in src/common/Thread.cc). 6. Improve the FreeBSD init scripts in the Ceph stack, both for testing purposes and for running Ceph on production machines. Work on ceph-disk and ceph-deploy to make it more FreeBSD- and ZFS-compatible. 7. Build a test cluster and start running some of the teuthology integration tests on it. Teuthology wants to build its own libvirt and that does not quite work with all the packages FreeBSD already has in place. There are many details to work out here. 8. Design a vitual disk implementation that can be used with bhyve and attached to an RBD image. __________________________________________________________________ OpenBSM Links OpenBSM: Open Source Basic Security Module (BSM) Audit Implementation URL: http://www.openbsm.org OpenBSM on GitHub URL: https://github.com/openbsm/openbsm FreeBSD Audit Handbook Chapter URL: https://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/audit.h= tml DTrace Audit Provider URL: https://reviews.FreeBSD.org/D10149 DARPA CADETS project URL: https://www.cl.cam.ac.uk/research/security/cadets/ TODO List on GitHub URL: https://github.com/openbsm/openbsm/blob/master/TODO Contact: Christian Brueffer Contact: Robert Watson Contact: TrustedBSD audit mailing list OpenBSM is a BSD-licensed implementation of Sun's Basic Security Module (BSM) API and file format. It is the userspace side of the CAPP Audit implementations in FreeBSD and Mac OS X. Additionally, the audit trail processing tools are expected to work on Linux. During this quarter, experimental support for UUIDs in BSM trails was added to OpenBSM. A DTrace audit provider using this functionality has been developed as part of the DARPA CADETS project and is in review (https://reviews.FreeBSD.org/D10149). In the OpenBSM GitHub repository, support for Coverity static analysis was added via TravisCI. Additionally, the OpenBSM 1.2-alpha5 release has been merged into the FreeBSD HEAD branch. This project was sponsored by DARPA/AFRL (in part). Open tasks: 1. Test the latest release on different versions of FreeBSD, Mac OS X and Linux. Testing on the latest versions of Mac OS X would be particularly appreciated. 2. Fix problems that have been reported via GitHub and the FreeBSD bug tracker. 3. Implement the features mentioned in the TODO list on GitHub. __________________________________________________________________ Porting Software to CloudABI: Sandboxed Bitcoin! Links How to Use CloudABI on FreeBSD URL: https://nuxi.nl/cloudabi/freebsd/ LevelDB for CloudABI URL: https://nuxi.nl/blog/2017/02/18/porting-leveldb-to-cloudabi.html Memcached for CloudABI URL: https://nuxi.nl/blog/2017/03/15/sandboxed-memcached.html Bitcoin for CloudABI URL: https://laanwj.github.io/2017/03/02/porting-bitcoin-core-to-clouda= bi.html Contact: Ed Schouten CloudABI is a framework that allows you to develop strongly sandboxed applications a lot more easily. It is a programming environment that exclusively uses FreeBSD's Capsicum facilities. Any features incompatible with Capsicum have been removed entirely, which means that it is easier to determine how code needs to be adjusted to behave correctly while sandboxed. In essence, you only need to patch up the code until it builds. Last year we have managed to port a lot of exciting libraries over to CloudABI. Highlights include sandboxing aware versions of Boost and LevelDB. Now that these libraries are readily available, we are at the point where we can shift our focus towards porting full applications. In late February one of the lead developers of the Bitcoin reference implementation got in touch, as he is very interested in creating a copy of Bitcoin that is better protected against security bugs. You do not want a security bug in the networking/consensus code to allow an attacker to steal coins from your local wallet! As I think that this is a use case that demonstrates the strength of CloudABI well, I've made addressing any issues reported by the Bitcoin developers a top priority. Once the Bitcoin port is complete, we want to provide binary packages of it as well. This project was sponsored by Nuxi, the Netherlands. Open tasks: 1. Though getting Bitcoin to work is pretty awesome, don't let that distract us from porting other pieces of software over as well! Are you the maintainer of a piece of software that could benefit from sandboxing? Be sure to try building it using the CloudABI toolchain! 2. One of the pieces of software that got ported over to CloudABI some time ago is Memcached. Are you a user of Memcached? If so, feel free to give the sandboxed version of Memcached for CloudABI a try! 3. So far, CloudABI can be used to run software written in C, C++ and Python. Would you like to see any other programming language work on CloudABI as well? Be sure to help out! __________________________________________________________________ Support for eMMC Flash and Faster SD Card Modes Contact: Marius Strobl In r315430, support for eMMC partitions has been added to mmc(4) and mmcsd(4) in FreeBSD 12. Besides the user data area, i.e., the default partition, eMMC v4.41 and later devices can additionally provide up to: * 1 enhanced user data area partition * 2 boot partitions * 1 RPMB (Replay Protected Memory Block) partition * 4 general purpose partitions (optionally with an enhanced or extended attribute) Apart from simply subdividing eMMC flash devices or having UEFI code in the boot partition, as is done on some Intel NUCs, another use case for partition support is the activation of pseudo-SLC mode, which manufacturers of eMMC chips typically associate with the enhanced user data area and/or the "enhanced" attribute of general purpose partitions. In order to be able to partition eMMC devices, r315430 also added a Linux-compatible ioctl(2) interface to mmcsd(4). This allows the use of the GNU mmc-utils (found in ports as sysutils/mmc-utils) on FreeBSD. Besides partitioning eMMC devices, the mmc tool can also be used to query for lifetime estimates and pre-EOL information of eMMC flash, as well as to query some basic information from SD cards. CAVEAT EMPTOR: Partitioning eMMC devices is a one-time operation. Additionally, in order to make eMMC flash devices more usable, support for DDR (Dual Data Rate) bus speed mode at a maximum of 52 MHz (DDR52) has been added to mmc(4) and sdhci(4) in r315598, which will appear in FreeBSD 12. Compared to high speed mode (the previous maximum) at 52 MHz, DDR52 mode increases the performance of the tested eMMC chips from ~45 MB/s to ~80 MB/s. So far, support for DDR52 mode has been enabled for the eMMC controllers found in the Intel Apollo Lake, Bay Trail and Braswell chipsets. Note, however, that the eMMC and SDHCI controllers of the Apollo Lake variant occasionally lock up due to a silicon bug (which is independent of running in DDR52 mode). The only viable workaround for that problem appears to be the implementation of support for ADMA2 mode in sdhci(4) (currently, sdhci(4) supports only the encumbered SDMA mode or no DMA at all). However, r315598 also brought in infrastructure and a fair amount of code for using even faster transfer modes with eMMC devices and SD cards respectively, i.e., up to HS400ES with eMMC and the UHS-I modes up to SDR104 with SD cards. The intent is to merge these changes back to FreeBSD 10 and 11. Open tasks: 1. Add support for eMMC HS200, HS400, and HS400ES transfer modes. 2. Add support for SD card UHS-I transfer modes (SDR12 to SDR104). 3. Make mmcsd(4) more robust and correctly follow the relevant specifications for existing features, e.g., calculate and handle erase timeouts, do a SEND_STATUS when CMD6 is invoked with an R1B response to the extent not already fixed as part of r315430, get the remainder of the existing code to properly check and handle return codes, etc. __________________________________________________________________ TrustedBSD Links TrustedBSD Website URL: http://www.trustedbsd.org TrustedBSD on GitHub URL: https://github.com/trustedbsd Contact: Christian Brueffer Contact: Robert Watson Contact: TrustedBSD announce mailing list The TrustedBSD Project is an open-source community developing advanced security features for the open-source FreeBSD operating system. Started in April 2000, the project developed support for extended attributes, access control lists (ACLs), UFS2, OpenPAM, security event auditing, OpenBSM, a flexible kernel access control framework, mandatory access control, and the GEOM storage layer. The results of this work may be found not just in FreeBSD, but also NetBSD, OpenBSD, Linux, and Apple's Mac OS X and iOS operating systems. Today, the project continues to maintain and enhance these mature features in FreeBSD. During this quarter, the TrustedBSD project transitioned from the FreeBSD Perforce server to GitHub. This was made possible by Alexis Sarghel, who owned the user "trustedbsd" on GitHub and graciously transferred this account to the TrustedBSD project. To date, the repositories hosting the TrustedBSD website and the SEBSD repository have been moved. __________________________________________________________________ Kernel FreeBSD on Hyper-V and Azure Links FreeBSD Virtual Machines on Microsoft Hyper-V URL: https://wiki.FreeBSD.org/HyperV Supported Linux and FreeBSD Virtual Machines for Hyper-V on Windows URL: https://technet.microsoft.com/en-us/library/dn531030.aspx Contact: Sepherosa Ziehau Contact: Hongjiang Zhang Contact: Dexuan Cui Contact: Kylie Liang SR-IOV support for NICs is implemented. So far, we have only tested with the Mellanox ConnectX-3 VF card, which works despite some issues (Bug 216493: https://bugs.FreeBSD.org/bugzilla/show_bug.cgi?id=3D216493). Updates for UEFI VMs (i.e., Hyper-V Generation 2 VMs): 1. After the loader issue (Bug 211746) is fixed, UEFI VMs can now boot with Secure Boot disabled; 2. A synthetic keyboard driver has been added. Currently it is only in HEAD, but MFCs to stable/10 and stable/11 are planned to occur soon; 3. A SCSI DVD detection issue (Bug 218248) was fixed. Without the fix, the VM would fail to boot. This project was sponsored by Microsoft. __________________________________________________________________ Intel 10G and 40G Network Driver Updates Links Commit adding X553 ix/ixv Support for iflib URL: https://reviews.FreeBSD.org/D9851 Commit converting ixgbe to iflib URL: https://reviews.FreeBSD.org/D5213 Contact: Jeb Cramer Contact: Eric Joyner Contact: Krzysztof Galazka This driver update is for the Intel ix/ixv and ixl/ixlv network drivers, and includes support for several new hardware releases. ix/ixv: * Added support for X553 SoC devices based on the Denverton platform ixl/ixlv: * Added support for X722 10G SoC devices based on the Lewisburg chipset * Added an interface for the upcoming iWarp driver for X722 devices * Added support for XXV710 25G devices Open tasks: 1. ix/ixv iflib support is currently under review in Phabricator. It will be refactored to include D5213. 2. Initial work for ixl/ixlv iflib support is in progress. __________________________________________________________________ Linuxulator Contact: Dimitry Chagin Contact: Edward Tomasz Napiera=C5=82a Contact: Mahdi Mokhtari In this quarter, we are pleased to announce two (of many) works achieved in the Linuxulator. We added a new placeholder marker UNIMPLEMENTED to accompany the previously existing DUMMY, for distinguishing syscalls that the Linux kernel itself does not implement from those that we currently do not implement. Now our linux_dummy.c is clearer for newcomers to follow, and they will quickly know which areas they can start working on. Support for two new syscalls, preadv and pwritev, was added to the Linuxulator. Open tasks: 1. We plan to implement the execveat syscall for the native FreeBSD syscall table and then port/wrap it for use in the Linuxulator. __________________________________________________________________ MMC Stack Using the CAM Framework Links Project Information URL: https://bakulin.de/freebsd/mmccam.html Source Code URL: https://github.com/kibab/FreeBSD/tree/mmccam-collapsed-commits Contact: Ilya Bakulin The goal of this project is to reimplement the existing MMC/SD stack using the CAM framework. This will permit utilizing the well-tested CAM locking model and debugging features. It will also be possible to process interrupts generated by the inserted card, which is a prerequisite for implementing the SDIO interface. SDIO support is necessary for communicating with the WiFi/BT modules found on many development boards, such as the Raspberry Pi 3. Another feature that the new stack will have is support for sending SD commands from userland applications using cam(3). This will allow for building device drivers in userland and make debugging much easier. The new stack is able to attach to an SD card and bring it to an operational state so that it is possible to read and write to the card. The stack has been tested to work on the Beaglebone Black and Wandboard Quad platforms. Currently the code is being prepared for inclusion in the FreeBSD source tree. cam(3) is being extended to support SDIO-specific functions (reading registers, managing interrupts, etc.). Open tasks: 1. Integrate the code into FreeBSD HEAD to facilitate testing. 2. Begin writing a driver for Broadcom-based WLAN chips (found on the Raspberry Pi 3 and Wandboard). 3. Begin writing a driver for Marvell-based WLAN chips (found on the GlobalScale Dreamplug and some Chromebooks). __________________________________________________________________ pNFS Server Plan B Contact: Rick Macklem Parallel NFS (pNFS) is an extension to the NFSv4 protocol that allows for file accesses within a single logical mount to be performed against multiple file servers, with the potential for data access to occur in parallel. The pNFS "layout" in use specifies how the division occurs, with metadata operations occurring against the main server, and bulk data operations (read/write/setattr/etc.) occurring via a layout-specific scheme between the client and data servers. My first attempt at a pNFS server using GlusterFS was a dud. It worked, but performance was so poor that it was not usable. This attempt that I call "Plan B", only uses FreeBSD, with one FreeBSD server handling the metadata operations and multiple FreeBSD servers configured to serve data. An NFSv4.1 client that supports the pNFS File Layout will be able to read and write to the data servers directly, spreading out the RPC load and allowing growth beyond that of what a single FreeBSD NFS server could achieve. There is no support for the Flex Files Layout or mirroring at this time. I hope to use the Flex Files Layout to add mirroring support over the next year or so. Striping is also not supported, but I have no plans for implementing it at the moment. Plan B is working quite well now and should be available for testing by the end of April. I will announce how to do this on the freebsd-fs@FreeBSD.org mailing list when it is available. Open tasks: 1. Testing by others will be needed, once it is available. __________________________________________________________________ Architectures 64-bit PowerPC Book-E Support Contact: Justin Hibbits The Book-E platform target now supports 64-bit mode ("powerpc64"). It includes a 63-bit address space split, but the page table directory list uses holes to expand to the full address space, leaving gaps in the address space where page mappings are repeated. This may change in the future. As with the AIM powerpc64 port, Book-E supports running powerpc (32-bit) binaries as well, and has even been tested with a 32-bit init and 64-bit shell. Several of the SoC drivers are supported, however, the dTSEC ethernet controller is not yet supported. Work is ongoing to support it. A QORIQ64 config is included, targeting the P5 and T* series SoCs from Freescale. Thanks to Juniper Networks for providing patches against an older internally maintained FreeBSD version, which enabled this porting effort, and for providing historical context for quirks of the pmap changes. Open tasks: 1. Port the dTSEC driver to 64-bit. There are assumptions in the reference driver of operating in a 32-bit environment. It may be easier to port the Linux driver instead, which would also give ARM support for this ethernet controller. 2. Take advantage of pointer alignment to squeeze more bits out of the page tables; it should be possible to squeeze at least 3 more bits out, one at each level. __________________________________________________________________ FreeBSD on Marvell Armada38x Contact: Marcin Wojtas Contact: Zbigniew Bodek Final testing and productionization of support for the Marvell Armada38x platform is under way. The rebase and cleanup is going well, with patches functioning on top of HEAD and ready for upstreaming. Specific tasks completed include: * Platform benchmarking and low-level optimizations (internal bus, L1/L2 cache prefetch) -- already submitted) * Enable the PL310 L2 cache controller -- currently under review * NETA tests, optimizations and PHY-handling rework * e6000sw PHY handling rework and fixes * Fix and enable performance counter support * Fix timers and extract watchdog support to a separate driver * Crypto driver fixes -- merged * AHCI controller support -- merged * Thermal driver -- merged * Merge additional support for new boards (SolidRun ClearFog and DB-88F6285-AP) This project was sponsored by Stormshield, and Semihalf. Open tasks: 1. Submit the remaining fixes and drivers. __________________________________________________________________ FreeBSD/s390x Attempt III Contact: Bjoern A. Zeeb A long time ago, in the FreeBSD 5 times, there was an initial port of FreeBSD to s390 (32bit) and s390x (64bit) which booted past init on good days in an emulator. As an attempt to revive the s390x/systemz efforts I started to get FreeBSD s390x to build with clang/llvm 3.9. At this time, it is possible to build world and a GENERIC kernel skeleton (not doing anything yet) using external binutils. The primary idea of this initial work was to allow for incremental addition of the necessary architecture-specific code. Having the build framework in place will allow third-party developers to simply type make, as they are willing to contribute to the port without having to know FreeBSD build specifics. After some cleanup and further updates to a more recent HEAD I am planning to push the current work to a public repo to facilitate collaboration. Open tasks: 1. Write a wiki page with per-architecture specific tasks that need to be done, based on the current work and the experience from arm64 and riscv. 2. Implement both the userspace and kernel per-architecture gaps. 3. Figure out a way to get access to IBM's zPDT or better emulators to ease implementation, testing, and debugging. __________________________________________________________________ Ports MySQL Links MySQL80 Overview URL: https://www.mysql.com/why-mysql/presentations/mysql-80-overview/ MySQL80 InnoDB New Features URL: https://www.mysql.com/why-mysql/presentations/innodb-whats-new-mys= ql-80/ Contact: Mahdi Mokhtari Contact: Mark Felder This quarter a new -dev version of MySQL landed in the Ports Collection, MySQL 8.0. It introduces many new features, though we had to (re)-patch parts of it which were merged by MySQL from MySQL5.7. We also updated MySQL 5.6 to its latest version and closed many PRs related to it, mostly relating to using FreeBSD-provided ports for libraries instead of the bundled copies. And of course there were plenty of security updates. We can also report that the problem of having to specify ${mysql_optfile}, which some people encountered while using MySQL, is now considered to be solved in all MySQL versions: 5.6, 5.7, and 8.0. Now the init script will search all default locations, for backwards compatibility with the variety of locations used for configuration files, before it gives up and reports an error. Open tasks: 1. Test the new version and report problems. __________________________________________________________________ Rust Links Wiki Portal URL: https://wiki.FreeBSD.org/Rust Guide to Bootstraping Rust on FreeBSD URL: https://gist.github.com/dumbbell/b587da50ef014078da9e732a4331ebad Bug Report to Track Progress on Bootstrapping URL: https://bugs.FreeBSD.org/bugzilla/show_bug.cgi?id=3D216143 Contact: Jean-S=C3=A9bastien P=C3=A9dron Contact: Thomas Zander In the Ports Collection, Rust was updated to 1.16.0 and Cargo to 0.17.0, the latest versions at the time of this writing. lang/rust-nightly was also updated to a snapshot from February and it is now enabled on i386. It is lagging a bit behind upstream, but Rustup works nicely on FreeBSD if you need to try any versions/channels of Rust. Work has started to bootstrap Rust on non-x86 architectures. Patches to add FreeBSD/aarch64 support were submitted and accepted upstream. FreeBSD/sparc64 is in progress. The lang/rust-nightly port is also being adapted to compile natively on FreeBSD/aarch64. This work is critical, in particular because Firefox will shortly require Rust. If you want to help, please refer to the guide linked above. The compiler, rustc, is crashing sometimes when there is a compilation error. Therefore, there is a bit of work to do to improve stability. There is some code duplication between lang/rust* and devel/cargo. Those Makefiles deserve a bit of cleanup. It might be useful to create a USES=3Drust Makefile helper. Open tasks: 1. Bootstrap Rust on more platforms. 2. Investigate compiler crashes. 3. Create a USES=3Drust Makefile helper and simplify the Rust and Cargo ports. 4. Investigate how to speed up lang/rust* compilation time. __________________________________________________________________ Documentation The FreeBSD Dutch Documentation Project Links The Dutch Translation Project URL: https://www.FreeBSD.org/docproj/translations.html#dutch Contact: Ren=C3=A9 Ladan Contact: Remko Lodder Work has started on an initial translation of the FreeBSD Handbook to the Dutch language via the "po" system. While we have an (outdated) version of the Handbook available via the older XML files, we are now trying to get back into shape with the PO file. Rene started working on two articles already and did some translation of strings for the FDP-Primer, while Remko has started working on the Handbook. If you think you can assist with either, please send Rene and Remko an email so that we can start coordinating work. In addition, since we have a translation set already from the XML files, it would be interesting to see whether we can merge them easily into the PO structure. If you have ideas on that, contact us a.s.a.p. This project was sponsored by Snow B.V. (in part). Open tasks: 1. Identify a way to merge the current XML translations into the nl_NL.po files. 2. Merge the translations into the .po files. 3. Update the remaining open items into the po files. 4. Remove the old/outdated translation files from the main repo and use the po and book.xml files to generate the Dutch handbook and other files. 5. Identify whether we can also translate the htdocs pages via the PO system. __________________________________________________________________ --A6N2fC+uXW/VQSAv Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQGgBAABCgAGBQJZGoM+AAoJECjZpvNk63UShiEMHiNj+z/V8LxFhIyFRTsKOJNQ KgEiR6NuUgGSYoanKkzSf2BO5MnhfbN3tSnxMx+WphyoV1WFdSiYBpgZEHOGWmta Z3pG6ov4n8IrHwhX71CoWcwawumDcA6aUrPoHlkJcG0HfLiyfp47BjHS85RmneR0 6BxcrvaCBkguL1fyiQUBlHqyhpFK0GqUBdihvkAUKFBjfXmPFLvmlJczrrDghbn6 ALD948qxIrGvvjAidp19gwft+9BMi6uxxLr+WAHQD5MejF3y8w7D1KPv3cJiaUV8 NULjQr+bGqkfvtRGKs94MyQdsvM+71QLsrpaVTdckMFlxTsRbRSkzzNGKWoi6vNR HF34QWqEE3upiqIEncSpDQY1wHi0yaL8VqAANavfUQT/xY1ZVwxdGaqx8mtUts4r T2solV102RYjVtXeS97/8u+1nqq8h9IVmttmQPLI8hj6MKCkurE0uOr169gXBmoy IV0A+cxjC6D2cKVRS5UwOjapt32l6bQQbgwADf+D8gwNHMk= =D2eA -----END PGP SIGNATURE----- --A6N2fC+uXW/VQSAv-- From owner-freebsd-hackers@freebsd.org Tue May 16 18:00: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 037EFD70897; Tue, 16 May 2017 18:00:17 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id D52896D8; Tue, 16 May 2017 18:00:16 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id v4GI080B035243 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 16 May 2017 11:00:09 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id v4GI03I7035241; Tue, 16 May 2017 11:00:03 -0700 (PDT) (envelope-from sgk) Date: Tue, 16 May 2017 11:00:02 -0700 From: Steve Kargl To: Bruce Evans Cc: freebsd-hackers@freebsd.org, freebsd-numerics@freebsd.org Subject: Re: Implementation of half-cycle trignometric functions Message-ID: <20170516180002.GA35211@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu References: <20170428165658.GA17560@troutmask.apl.washington.edu> <20170429035131.E3406@besplex.bde.org> <20170428201522.GA32785@troutmask.apl.washington.edu> <20170429070036.A4005@besplex.bde.org> <20170428233552.GA34580@troutmask.apl.washington.edu> <20170429005924.GA37947@troutmask.apl.washington.edu> <20170429151457.F809@besplex.bde.org> <20170429194239.P3294@besplex.bde.org> <20170513205517.GA91911@troutmask.apl.washington.edu> <20170514071942.T1084@besplex.bde.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170514071942.T1084@besplex.bde.org> User-Agent: Mutt/1.7.2 (2016-11-26) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 May 2017 18:00:17 -0000 On Sun, May 14, 2017 at 08:30:34AM +1000, Bruce Evans wrote: > On Sat, 13 May 2017, Steve Kargl wrote: > > > Based on other replies in this email exchange, I have gone back > > and looked at improvements to my __kernel_{cos|sin|tan}pi[fl] > > routines. The improvements where for both accuracy and speed. > > I really don't want another set of kernels (or more sets for degrees > instead of radians, and sincos). Ugh. __kernel_tan(x,y,iy) and __kernel_tanl(x,y,iy) seem to have inverted logic for iy. That is, iy = 1 for __kernel_tan() needs to be changed to y = -1 for __kernel_tanl(), and vice versa. -- Steve 20170425 https://www.youtube.com/watch?v=VWUpyCsUKR4 20161221 https://www.youtube.com/watch?v=IbCHE-hONow From owner-freebsd-hackers@freebsd.org Wed May 17 00:23:48 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 16D05D6D5A9; Wed, 17 May 2017 00:23:48 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id D4B9E1B9E; Wed, 17 May 2017 00:23:47 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id v4H0NkMH042616 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 16 May 2017 17:23:46 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id v4H0NkKx042615; Tue, 16 May 2017 17:23:46 -0700 (PDT) (envelope-from sgk) Date: Tue, 16 May 2017 17:23:46 -0700 From: Steve Kargl To: freebsd-current@freebsd.org, freebsd-hackers@freebsd.org Subject: UC Berkeley 4-clause copyright Message-ID: <20170517002346.GA42582@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.7.2 (2016-11-26) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 May 2017 00:23:48 -0000 The files in lib/msun/bsdsrc contain the 4-clause UC Berkeley Copyright. Supposedly UCB no longer enforces clause 3. Can clause 3 be removed? -- Steve 20170425 https://www.youtube.com/watch?v=VWUpyCsUKR4 20161221 https://www.youtube.com/watch?v=IbCHE-hONow From owner-freebsd-hackers@freebsd.org Wed May 17 00:37:58 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 66778D6DC9B for ; Wed, 17 May 2017 00:37:58 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 38E6E791 for ; Wed, 17 May 2017 00:37:57 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x22f.google.com with SMTP id f102so282260ioi.2 for ; Tue, 16 May 2017 17:37:57 -0700 (PDT) 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=fXXe8+2YgEyttyOuSwHpJX3RCuS5qAYVozHpGSSwWmQ=; b=K+rEZH9iGSCRpWWIooE9lAH780JVQoW5Cx5SSc5wgBVRydJVxnUpTVwZ2KkOwzJRZu ciZ1nagSTQxKMc+V9Qgt7kTQl1AmGc4vihkZxoMBEdjkuavN+7HGYseZlo5TbfI7oHRi MPdyYG5SOzhbos7xKW7pXDtQaSbGUojrE58UT9s1/3OBs0h2guYmhpsAk2EH+NAzqJmN 48ckUUmYfR2iP/y0KS7100bBJ6VHXlraeavSiI6Zt/HPzcCA06vxLIz6qg/wOfBIaX4r HBrfPgkwfzn6do45NfyqT0WfTFtPuaGL/t56FdNXw26biYCjAAB6CKcalCxKojig4WOj W0zA== 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=fXXe8+2YgEyttyOuSwHpJX3RCuS5qAYVozHpGSSwWmQ=; b=Ys68qrBLE0nkaqzcfXxG34kNo2oheCrHZlzaMZJHl3SyWZGy2qLlyqHyEAHwKxzzPL idiKjs3WpRNUrjgLGFdLwG0RqazgKzL6FIFroS4JeWDT7S7nIzUWidYSQnRtApvVLbWS nkNtRB8akI+cQtNvODXAhSla88nLsp74+CnC1Ccxp/RQEAgO7kN84CTpK++jJzjXODhA uwBQoY14AoNLKthBzVIFteSDvAb7BkIOZVtdzZ8LpAdOHD79KOL75RtXtCgCXtFxWzIF z1l+kwUNNZqBQRUtTNN5ogCBehqj25YjadSyU7LJeFJjfKiiXgQgUg/8ZpJhvq7R6aMD 5A3w== X-Gm-Message-State: AODbwcBEnfEUlQlTNFqpFULpXiXj2O3hUzut80FQmagZUsnK/j/3XqL3 JXCDWiwpGl20YR/xWNbh1V5bWgZ6p3/q X-Received: by 10.107.188.132 with SMTP id m126mr806501iof.148.1494981476918; Tue, 16 May 2017 17:37:56 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.126.6 with HTTP; Tue, 16 May 2017 17:37:56 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:51cb:c6:1f52:3765] In-Reply-To: <20170517002346.GA42582@troutmask.apl.washington.edu> References: <20170517002346.GA42582@troutmask.apl.washington.edu> From: Warner Losh Date: Tue, 16 May 2017 18:37:56 -0600 X-Google-Sender-Auth: 7Hh09TITOTM88aHOVnW52KQlAuQ Message-ID: Subject: Re: UC Berkeley 4-clause copyright To: Steve Kargl Cc: FreeBSD Current , "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 May 2017 00:37:58 -0000 Yes. Remove it. It's convention these days to also renumber. It was likely missed. Are there other copyright holders? If so, that would be why I didn't remove it at the time years ago.... But I may have missed them too. Warner On Tue, May 16, 2017 at 6:23 PM, Steve Kargl wrote: > The files in lib/msun/bsdsrc contain the 4-clause UC Berkeley > Copyright. Supposedly UCB no longer enforces clause 3. Can > clause 3 be removed? > > -- > Steve > 20170425 https://www.youtube.com/watch?v=VWUpyCsUKR4 > 20161221 https://www.youtube.com/watch?v=IbCHE-hONow > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-hackers@freebsd.org Wed May 17 00:48:40 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 D95BED7019A; Wed, 17 May 2017 00:48:40 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B02E0E42; Wed, 17 May 2017 00:48:40 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id v4H0md8k042823 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 16 May 2017 17:48:39 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id v4H0mdCS042822; Tue, 16 May 2017 17:48:39 -0700 (PDT) (envelope-from sgk) Date: Tue, 16 May 2017 17:48:39 -0700 From: Steve Kargl To: Warner Losh Cc: FreeBSD Current , "freebsd-hackers@freebsd.org" Subject: Re: UC Berkeley 4-clause copyright Message-ID: <20170517004839.GA42771@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu References: <20170517002346.GA42582@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.7.2 (2016-11-26) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 May 2017 00:48:41 -0000 On Tue, May 16, 2017 at 06:37:56PM -0600, Warner Losh wrote: > On Tue, May 16, 2017 at 6:23 PM, Steve Kargl > wrote: > > The files in lib/msun/bsdsrc contain the 4-clause UC Berkeley > > Copyright. Supposedly UCB no longer enforces clause 3. Can > > clause 3 be removed? > > > Yes. Remove it. It's convention these days to also renumber. It was > likely missed. > > Are there other copyright holders? If so, that would be why I didn't > remove it at the time years ago.... But I may have missed them too. > lib/msun/b_log.c and lib/msun/mathimpl.h have appear to have onlu UCB in file (other than bde and das in the RCS string). lib/msun/b_tgamma.c has a standard 4-clause BSD license with the years 1992 and 1993 listed. But, later in the file there is the comment /* * This code by P. McIlroy, Oct 1992; * * The financial support of UUNET Communications Services is greatfully * acknowledged. */ IANAL, so I don't know if this triggers the "and its contributors." portion of clause 3. lib/msun/b_exp.c has a standard 4-clause BSD license with the years 1985 and 1993 listed. Later in the file is KC Ng's ChangeLog like annotation /* EXP(X) * RETURN THE EXPONENTIAL OF X * DOUBLE PRECISION (IEEE 53 bits, VAX D FORMAT 56 BITS) * CODED IN C BY K.C. NG, 1/19/85; * REVISED BY K.C. NG on 2/6/85, 2/15/85, 3/7/85, 3/24/85, 4/16/85, 6/14/86. Again, IANAL. -- Steve 20170425 https://www.youtube.com/watch?v=VWUpyCsUKR4 20161221 https://www.youtube.com/watch?v=IbCHE-hONow From owner-freebsd-hackers@freebsd.org Wed May 17 00:51: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 93936D70500 for ; Wed, 17 May 2017 00:51:31 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (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 541C3128A for ; Wed, 17 May 2017 00:51:31 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x235.google.com with SMTP id o12so393188iod.3 for ; Tue, 16 May 2017 17:51:31 -0700 (PDT) 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=enY0NG/TmAzj+fZe4bIAchRLuJf7YCu5LCBPoVMKWMs=; b=dA2RWT48hxHannltGEcGIGi0U1kuW59FGiYKk07k0f4xwmyx4T0/iX/FaubxNB/r53 c/4p44mmKuvqFu+szlff3G7TuRINtrDZfiv4eDH2RhE/BX6oHul028smMSoQd0f0DX6H AhPI9drbtkJ6HGo/mVfUpntVXzFY9rpePhwPtIpWwkr+8XeNJNblJI18FxQWJhiSl2I2 8KrBFKN4u5rxUOswturQKCEeC54cimviHtVhv3oDf6k0J3yQCNTgSPZSsGapXpJx48VB 1WhGhJeraEmZ2Usde+BjwTDV3GXhntlz8oo1R9jAZgnKr21unJoSyhB3yNWRRhAT4YLh GfmQ== 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=enY0NG/TmAzj+fZe4bIAchRLuJf7YCu5LCBPoVMKWMs=; b=MyGSA5Ilm5TmDHkDwt9+LzZqpQDoOPHvfgOClniYoptAAWZSlUGm0DNO7dt8Wihrs9 bfAR3/omw3H1u+dYKQCHBVNqW4g2tguPL5iq/NC6i0r760jVg2iEhLeriThCh+xX4KOt 7I76WjHFQ8jedB70zljQ92pDAlXV9PzKIL7hQjRULYwIoKKG/1PUvsrk/Onde+uoa/Z5 HgkLEh8S5uTVIYUBvdD29q4BqGLA6aqgg4b8tbdMoSDdFQJimZJ7zlAykWcMUdQsEYMG gZYz2psqX7cPiBP10wIfk4imabB1jDU6ZDbpd+L63ftp96gGDZ48IzadGoQo1fecH8ul BjjQ== X-Gm-Message-State: AODbwcB4A+kdyk1gL29bpTXJtuNBMUfC0ibA13dsd0STufa3wjJkokRM H6/7SL4UaJ0/aqkEVkgctQqn40rqnpHm X-Received: by 10.107.188.132 with SMTP id m126mr851122iof.148.1494982290519; Tue, 16 May 2017 17:51:30 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.126.6 with HTTP; Tue, 16 May 2017 17:51:30 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:6897:8c9a:30f5:4de8] In-Reply-To: <20170517004839.GA42771@troutmask.apl.washington.edu> References: <20170517002346.GA42582@troutmask.apl.washington.edu> <20170517004839.GA42771@troutmask.apl.washington.edu> From: Warner Losh Date: Tue, 16 May 2017 18:51:30 -0600 X-Google-Sender-Auth: Bk8LDw0yXNKnVOdZZt4tmjdw3X8 Message-ID: Subject: Re: UC Berkeley 4-clause copyright To: Steve Kargl Cc: FreeBSD Current , "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 May 2017 00:51:31 -0000 If it says that it's copyright those people, that's an issue. If it doesn't then there's no issue. Doesn't look like it does. If you'd like, I can look at it an DTRT if you're unsure. Warner On Tue, May 16, 2017 at 6:48 PM, Steve Kargl wrote: > On Tue, May 16, 2017 at 06:37:56PM -0600, Warner Losh wrote: >> On Tue, May 16, 2017 at 6:23 PM, Steve Kargl >> wrote: >> > The files in lib/msun/bsdsrc contain the 4-clause UC Berkeley >> > Copyright. Supposedly UCB no longer enforces clause 3. Can >> > clause 3 be removed? >> > >> Yes. Remove it. It's convention these days to also renumber. It was >> likely missed. >> >> Are there other copyright holders? If so, that would be why I didn't >> remove it at the time years ago.... But I may have missed them too. >> > > lib/msun/b_log.c and lib/msun/mathimpl.h have appear to have > onlu UCB in file (other than bde and das in the RCS string). > > lib/msun/b_tgamma.c has a standard 4-clause BSD license with > the years 1992 and 1993 listed. But, later in the file there > is the comment > > /* > * This code by P. McIlroy, Oct 1992; > * > * The financial support of UUNET Communications Services is greatfully > * acknowledged. > */ > > IANAL, so I don't know if this triggers the "and its contributors." > portion of clause 3. > > lib/msun/b_exp.c has a standard 4-clause BSD license with the > years 1985 and 1993 listed. Later in the file is KC Ng's ChangeLog > like annotation > > /* EXP(X) > * RETURN THE EXPONENTIAL OF X > * DOUBLE PRECISION (IEEE 53 bits, VAX D FORMAT 56 BITS) > * CODED IN C BY K.C. NG, 1/19/85; > * REVISED BY K.C. NG on 2/6/85, 2/15/85, 3/7/85, 3/24/85, 4/16/85, 6/14/86. > > Again, IANAL. > > -- > Steve > 20170425 https://www.youtube.com/watch?v=VWUpyCsUKR4 > 20161221 https://www.youtube.com/watch?v=IbCHE-hONow From owner-freebsd-hackers@freebsd.org Wed May 17 00:55: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 5EC29D707A3; Wed, 17 May 2017 00:55:25 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 3A01917FC; Wed, 17 May 2017 00:55:25 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id v4H0tOqV042928 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 16 May 2017 17:55:24 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id v4H0tOVD042927; Tue, 16 May 2017 17:55:24 -0700 (PDT) (envelope-from sgk) Date: Tue, 16 May 2017 17:55:24 -0700 From: Steve Kargl To: Warner Losh Cc: FreeBSD Current , "freebsd-hackers@freebsd.org" Subject: Re: UC Berkeley 4-clause copyright Message-ID: <20170517005524.GA42906@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu References: <20170517002346.GA42582@troutmask.apl.washington.edu> <20170517004839.GA42771@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.7.2 (2016-11-26) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 May 2017 00:55:25 -0000 I don't have a commit bit. I just checked OpenBSD/NetBSD. They use a 3-clause license. -- steve On Tue, May 16, 2017 at 06:51:30PM -0600, Warner Losh wrote: > If it says that it's copyright those people, that's an issue. If it > doesn't then there's no issue. Doesn't look like it does. If you'd > like, I can look at it an DTRT if you're unsure. > > Warner > > On Tue, May 16, 2017 at 6:48 PM, Steve Kargl > wrote: > > On Tue, May 16, 2017 at 06:37:56PM -0600, Warner Losh wrote: > >> On Tue, May 16, 2017 at 6:23 PM, Steve Kargl > >> wrote: > >> > The files in lib/msun/bsdsrc contain the 4-clause UC Berkeley > >> > Copyright. Supposedly UCB no longer enforces clause 3. Can > >> > clause 3 be removed? > >> > > >> Yes. Remove it. It's convention these days to also renumber. It was > >> likely missed. > >> > >> Are there other copyright holders? If so, that would be why I didn't > >> remove it at the time years ago.... But I may have missed them too. > >> > > > > lib/msun/b_log.c and lib/msun/mathimpl.h have appear to have > > onlu UCB in file (other than bde and das in the RCS string). > > > > lib/msun/b_tgamma.c has a standard 4-clause BSD license with > > the years 1992 and 1993 listed. But, later in the file there > > is the comment > > > > /* > > * This code by P. McIlroy, Oct 1992; > > * > > * The financial support of UUNET Communications Services is greatfully > > * acknowledged. > > */ > > > > IANAL, so I don't know if this triggers the "and its contributors." > > portion of clause 3. > > > > lib/msun/b_exp.c has a standard 4-clause BSD license with the > > years 1985 and 1993 listed. Later in the file is KC Ng's ChangeLog > > like annotation > > > > /* EXP(X) > > * RETURN THE EXPONENTIAL OF X > > * DOUBLE PRECISION (IEEE 53 bits, VAX D FORMAT 56 BITS) > > * CODED IN C BY K.C. NG, 1/19/85; > > * REVISED BY K.C. NG on 2/6/85, 2/15/85, 3/7/85, 3/24/85, 4/16/85, 6/14/86. > > > > Again, IANAL. > > > > -- > > Steve > > 20170425 https://www.youtube.com/watch?v=VWUpyCsUKR4 > > 20161221 https://www.youtube.com/watch?v=IbCHE-hONow > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" -- Steve 20170425 https://www.youtube.com/watch?v=VWUpyCsUKR4 20161221 https://www.youtube.com/watch?v=IbCHE-hONow From owner-freebsd-hackers@freebsd.org Wed May 17 00:58: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 43556D70989; Wed, 17 May 2017 00:58:04 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 2A5641AF5; Wed, 17 May 2017 00:58:04 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id v4H0w3U6042970 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 16 May 2017 17:58:03 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id v4H0w3lW042969; Tue, 16 May 2017 17:58:03 -0700 (PDT) (envelope-from sgk) Date: Tue, 16 May 2017 17:58:02 -0700 From: Steve Kargl To: Warner Losh Cc: "freebsd-hackers@freebsd.org" , FreeBSD Current Subject: Re: UC Berkeley 4-clause copyright Message-ID: <20170517005802.GB42906@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu References: <20170517002346.GA42582@troutmask.apl.washington.edu> <20170517004839.GA42771@troutmask.apl.washington.edu> <20170517005524.GA42906@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170517005524.GA42906@troutmask.apl.washington.edu> User-Agent: Mutt/1.7.2 (2016-11-26) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 May 2017 00:58:04 -0000 In looking at NetBSD/OpenBSD's math_private.h, it seems the content of mathimpl.h have been tacked onto it. -- steve On Tue, May 16, 2017 at 05:55:24PM -0700, Steve Kargl wrote: > I don't have a commit bit. I just checked OpenBSD/NetBSD. > They use a 3-clause license. > > -- > steve > > On Tue, May 16, 2017 at 06:51:30PM -0600, Warner Losh wrote: > > If it says that it's copyright those people, that's an issue. If it > > doesn't then there's no issue. Doesn't look like it does. If you'd > > like, I can look at it an DTRT if you're unsure. > > > > Warner > > > > On Tue, May 16, 2017 at 6:48 PM, Steve Kargl > > wrote: > > > On Tue, May 16, 2017 at 06:37:56PM -0600, Warner Losh wrote: > > >> On Tue, May 16, 2017 at 6:23 PM, Steve Kargl > > >> wrote: > > >> > The files in lib/msun/bsdsrc contain the 4-clause UC Berkeley > > >> > Copyright. Supposedly UCB no longer enforces clause 3. Can > > >> > clause 3 be removed? > > >> > > > >> Yes. Remove it. It's convention these days to also renumber. It was > > >> likely missed. > > >> > > >> Are there other copyright holders? If so, that would be why I didn't > > >> remove it at the time years ago.... But I may have missed them too. > > >> > > > > > > lib/msun/b_log.c and lib/msun/mathimpl.h have appear to have > > > onlu UCB in file (other than bde and das in the RCS string). > > > > > > lib/msun/b_tgamma.c has a standard 4-clause BSD license with > > > the years 1992 and 1993 listed. But, later in the file there > > > is the comment > > > > > > /* > > > * This code by P. McIlroy, Oct 1992; > > > * > > > * The financial support of UUNET Communications Services is greatfully > > > * acknowledged. > > > */ > > > > > > IANAL, so I don't know if this triggers the "and its contributors." > > > portion of clause 3. > > > > > > lib/msun/b_exp.c has a standard 4-clause BSD license with the > > > years 1985 and 1993 listed. Later in the file is KC Ng's ChangeLog > > > like annotation > > > > > > /* EXP(X) > > > * RETURN THE EXPONENTIAL OF X > > > * DOUBLE PRECISION (IEEE 53 bits, VAX D FORMAT 56 BITS) > > > * CODED IN C BY K.C. NG, 1/19/85; > > > * REVISED BY K.C. NG on 2/6/85, 2/15/85, 3/7/85, 3/24/85, 4/16/85, 6/14/86. > > > > > > Again, IANAL. > > > > > > -- > > > Steve > > > 20170425 https://www.youtube.com/watch?v=VWUpyCsUKR4 > > > 20161221 https://www.youtube.com/watch?v=IbCHE-hONow > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > -- > Steve > 20170425 https://www.youtube.com/watch?v=VWUpyCsUKR4 > 20161221 https://www.youtube.com/watch?v=IbCHE-hONow > _______________________________________________ > 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" -- Steve 20170425 https://www.youtube.com/watch?v=VWUpyCsUKR4 20161221 https://www.youtube.com/watch?v=IbCHE-hONow From owner-freebsd-hackers@freebsd.org Thu May 18 10:04: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 CB530D700DE for ; Thu, 18 May 2017 10:04:35 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-8.reflexion.net [208.70.210.8]) (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 915441F83 for ; Thu, 18 May 2017 10:04:35 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 23325 invoked from network); 18 May 2017 10:04:27 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 18 May 2017 10:04:27 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Thu, 18 May 2017 06:04:27 -0400 (EDT) Received: (qmail 9924 invoked from network); 18 May 2017 10:04:27 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 18 May 2017 10:04:27 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id AC7E2EC7B25; Thu, 18 May 2017 03:04:26 -0700 (PDT) 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: head -r317820: An example TARGET_ARCH=powerpc panic with interesting information reported (PowerMac G5 so-called "Quad Core" context) Message-Id: <3D469253-A16F-4723-B459-38BE01FFB051@dsl-only.net> Date: Thu, 18 May 2017 03:04:26 -0700 Cc: freebsd-hackers@freebsd.org To: FreeBSD PowerPC ML X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 May 2017 10:04:35 -0000 Context: The context is a TARGET_ARCH=powerpc build used on an old PowerMac G5 so-called "Quad Core". Currently I'm using head -r317820 for investigating. I've been having problems with production-style kernel builds for TARGET_ARCH=powerpc getting occasional fatal kernel traps --but the debug kernel works and does not report anything odd. I see this even with pure gcc 4.2.1 based builds, not just my clang experiments. Also all the TARGET_ARCH=powerpc64 builds seem to work fine on the same machines. All the trap reports indicate pid 11 and one of the cpu idle threads, more cpu 0 than the others but not limited to one cpu/thread. Interesting evidence based on the trap frame: I caught a data storage interrupt fatal kernel trap from which the ddb information is interesting . . . For the fatal kernel trap notice for pid 11's cpu0 thread (there is a "timeout stopping cpus"): srr0 indicates 0x5e58e0 which is: sched_choose+0x100: lwz r30, -0x8(r11) in the build then in use. But lr is listed as: lr 0x5358d0, which is before srr0, lr pointing at: sched_choose+0xf0: lwz r0,4(r11) *** Does this ordering of lr vs. srr0 content make sense? Is it evidence of a problem? *** The code in the area looks like: 005358b8 li r0,-1 005358bc stb r0,152(r29) 005358c0 mfsprg r9,0 005358c4 lwz r28,4(r9) 005358c8 mr r3,r28 005358cc lwz r11,0(r1) => 005358d0 lwz r0,4(r11) 005358d4 mtlr r0 005358d8 lwz r28,-16(r11) 005358dc lwz r29,-12(r11) => 005358e0 lwz r30,-8(r11) 005358e4 lwz r31,-4(r11) 005358e8 mr r1,r11 005358ec blr The r3, r28, r11, r9, and r0 values in the trap frame do not seem to match the code. For example at 005358d0 the above would have r3=r28 but the "show reg" shows: r3 0x0 r28 0x7c2803c6 The r1 value and vmcore.3 content indicate 0x0147d6c0 for the later "lwz r28,-16(r11)". "show reg" reported both of the following for the trap frame: r1 0xdf5e58c0 r11 0xdf5e58c0 which would indicate r11 not being from the result of "lwz r11,0(r1)". vmcore.3 content indicates two things: A) The trap frame shows the 0xdf5e58c0 for r11. B) 0(r1) would have been 0xdf5e58e0 . In vmcore.3 0xdf5e58e0 has an associated lr value next to it: 0x5358ac, matching up with the return from the last bl in sched_choose: 005358a0 b 005358ac 005358a4 mr r4,r28 005358a8 bl 00500010 005358ac lbz r0,622(r28) So it looks as expected in vmcore.3 . Then either: a) The trap from is from prior to the "lwz r11,0(r1)" result. b) The 0(r1) access was not based on coherent/up-to-date cache/memory contents and so filled r11 with junk. c) The r11 value in the trap frame has been corrupted some other way. The trap frame shows: r9 0x1f8 But 0x1f8 is much smaller than what I see on a live system for sprg0: more like 0xf65f00 . And the 4(r9) would not get to a 0x7c2803c6 value from what I see in vmcore.3 . The trap frame's r0 0x4bfca6c1 does not fit with either "li r0,-1" nor the code: => 005358d0 lwz r0,4(r11) 005358d4 mtlr r0 (The trap frame reports lr as 0x5358d0.) (r0's value only exists in two places in vmcore.3, one being the trap frame.) The vmcore.3 and r1 would suggest the result of: 005358cc lwz r11,0(r1) => 005358d0 lwz r0,4(r11) 005358d4 mtlr r0 005358d8 lwz r28,-16(r11) 005358dc lwz r29,-12(r11) => 005358e0 lwz r30,-8(r11) 005358e4 lwz r31,-4(r11) 005358e8 mr r1,r11 should be the sequence of register assignments: r11 = 0xdf5e58e0 r0 = 0x00500460 lr = 0x00500460 r28 = 0x0147d6c0 r29 = 0x00d4d7c8 r30 = 0x00d1d6c4 r31 = 0xdf5e58e0 r1 = 0xdf5e58e0 None of which show up in the trap frame. But even the trap frame's 005358d0 would suggest the first of the above. As for the virtual address reported for the failure: virtual address = 0x7c2803ba There is only one register listed with a value near that: r28 0x7c2803a6 (This value is in vmcore.3 something like 677 times.) and: 0x7c2803ba - 0x7c2803a6 == 0x14 (20 decimal). But it does not fit for the code getting to 0x7c2803ba from r28. 0x7c2803ba only exists in 3 or so places in vmcore.3 (including the trap frame instance). I'm not sure how 0x7c2803ba ended up in the dar (or its spot in the trap frame) in vmcore.3 . Supporting detail: Looking around in the vmcore.3 file showed that the area I found with the proper back chain and lr links was present (this was debug.minidump=0), complete with having one of 3 instances of the failing virtual memory address (0x7c2803ba) near by --happening to be the dar value from the trap frame when I looked in detail. (Of course in vmcore.3 I'm seeing physical memory addresses offset by the dump's header size for locations of memory. So I'm learning what the mapping was by finding the region with the content.) Notes: I have evidence that changes in the memory layout of the kernel (such as by adding something to potentially use in investigating) changes the details of the failure behavior. I have had contexts where the failures would happen when the PowerMac involved was booted but not in active use. In other contexts I've had that not fail but something like "find / -name dog -print | more" leads to failure before completing. In the other context such things completed just fine. libkvm was never updated to deal with the powerpc and powerpc64 relocatable kernel format changes. On the PowerMac it seems to leave the kernel at its default place but the format is ET_DYN. More than just testing for ET_DYN is required in libkvm. And it appears that for powerpc and powerpc64 it never supported debug.minidump=0 . The open Bugzilla 219153 reports this issue and has more notes. === Mark Millard markmi at dsl-only.net From owner-freebsd-hackers@freebsd.org Thu May 18 21:22:40 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 A5755D6F17E for ; Thu, 18 May 2017 21:22:40 +0000 (UTC) (envelope-from rpokala@mac.com) Received: from mr11p00im-asmtp004.me.com (mr11p00im-asmtp004.me.com [17.110.69.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8D22D385 for ; Thu, 18 May 2017 21:22:40 +0000 (UTC) (envelope-from rpokala@mac.com) Received: from process-dkim-sign-daemon.mr11p00im-asmtp004.me.com by mr11p00im-asmtp004.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) id <0OQ6001002E9LV00@mr11p00im-asmtp004.me.com> for freebsd-hackers@freebsd.org; Thu, 18 May 2017 21:22:33 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mac.com; s=4d515a; t=1495142553; bh=HgqXUiH1Xpr6IMB51gSy+VYPxTBhe2f+iqDSHrazdo0=; h=Date:Subject:From:To:Message-id:MIME-version:Content-type; b=feN/VS9MRoMd4z4xraIWGNF8/hLXKePAjqCjIxXnifj0IceoUU7xbxR3yS3co1jPS a7fFPFHAwrpiEmg8QmNeddCTiuTmy4bWNZvGKSRDw6+Oj05biG3iFP8+uppY/lp9vI V2WFKeb3Artind/fPv7qtJAE+x6dxb+B8btpbr103Vnk8nwZPfFKMFtnAeh7Xrunt9 W0o2KFHmrVdDh8kJzia+BmX3jROEOKg0XmoVmZkX9PKbTk6ZXGEdb7aB2YVPGE+aMC sZ9fRz2AJ1/j3mBYRvcfGZNFHWv88wZ3Z3gGEQ+H8C0klOEDY9mylvpLr6EIcD7/WS nsDI0BHYu0rGA== Received: from icloud.com ([127.0.0.1]) by mr11p00im-asmtp004.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) with ESMTPSA id <0OQ600GEI3DIX300@mr11p00im-asmtp004.me.com> for freebsd-hackers@freebsd.org; Thu, 18 May 2017 21:22:31 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-05-18_05:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1034 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1701120000 definitions=main-1705180145 User-Agent: Microsoft-MacOutlook/f.21.0.170409 Date: Thu, 18 May 2017 14:22:30 -0700 Subject: iMC SMBus controller driver From: Ravi Pokala To: "freebsd-hackers@freebsd.org" Message-id: Thread-topic: iMC SMBus controller driver MIME-version: 1.0 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: 7bit X-Mailman-Approved-At: Thu, 18 May 2017 23:35:39 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 May 2017 21:22:40 -0000 Hi folks, In recent years, Intel has put an SMBus controller on the CPU's integrated Memory Controller (iMC). Does anyone have a driver for that? Even if it's not something that you're willing to open up, just knowing that someone has done it would be nice. (I'm specifically interested in Haswell/Broadwell Xeon, but I'd imagine the programming model is the same for the iMC/SMBus controller on all the recent CPUs.) Thanks, Ravi (rpokala@) From owner-freebsd-hackers@freebsd.org Fri May 19 08:31:14 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 76F6FD7317E for ; Fri, 19 May 2017 08:31:14 +0000 (UTC) (envelope-from sebastian.huber@embedded-brains.de) Received: from dedi548.your-server.de (dedi548.your-server.de [85.10.215.148]) (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 29C84CC3 for ; Fri, 19 May 2017 08:31:13 +0000 (UTC) (envelope-from sebastian.huber@embedded-brains.de) Received: from [88.198.220.130] (helo=sslproxy01.your-server.de) by dedi548.your-server.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.85_2) (envelope-from ) id 1dBcuk-000145-0l; Fri, 19 May 2017 10:05:34 +0200 Received: from [82.135.62.35] (helo=mail.embedded-brains.de) by sslproxy01.your-server.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1dBcuj-0004Eo-PU; Fri, 19 May 2017 10:05:33 +0200 Received: from localhost (localhost.localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id 0BBA52A003F; Fri, 19 May 2017 10:06:10 +0200 (CEST) Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id L1BCbzYUPCjM; Fri, 19 May 2017 10:06:07 +0200 (CEST) Received: from localhost (localhost.localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id ADF922A0047; Fri, 19 May 2017 10:06:07 +0200 (CEST) X-Virus-Scanned: amavisd-new at zimbra.eb.localhost Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id KfWJrQ2BjVbv; Fri, 19 May 2017 10:06:07 +0200 (CEST) Received: from [192.168.96.129] (unknown [192.168.96.129]) by mail.embedded-brains.de (Postfix) with ESMTPSA id 983592A003F; Fri, 19 May 2017 10:06:07 +0200 (CEST) Subject: Re: Improved Red-black tree implementation To: Jens Stimpfle , freebsd-hackers@freebsd.org References: <20170514050220.GA768@jstimpfle.de> From: Sebastian Huber Message-ID: <591EA74A.3080500@embedded-brains.de> Date: Fri, 19 May 2017 10:05:30 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <20170514050220.GA768@jstimpfle.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-Authenticated-Sender: smtp-embedded@poldinet.de X-Virus-Scanned: Clear (ClamAV 0.99.2/23397/Fri May 19 02:58:09 2017) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 May 2017 08:31:14 -0000 Hello, I use the BSD for RTEMS with a shared extract and insert=20 color implementation (this is similar to Linux): https://git.rtems.org/rtems/tree/cpukit/score/include/rtems/score/rbtree.= h#n206 https://git.rtems.org/rtems/tree/cpukit/score/src/rbtreeextract.c https://git.rtems.org/rtems/tree/cpukit/score/src/rbtreeinsert.c I did also some primitive benchmarking: https://github.com/sebhub/rb-bench It would be quite nice to have a implementation which=20 encodes the color in one of the pointers to save some memory. --=20 Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.huber@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine gesch=E4ftliche Mitteilung im Sinne des EHUG. From owner-freebsd-hackers@freebsd.org Fri May 19 09:22:10 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 EEBB0D7447C for ; Fri, 19 May 2017 09:22:10 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citapm.icyb.net.ua (citapm.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 49E88A0E for ; Fri, 19 May 2017 09:22:09 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citapm.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id MAA14484; Fri, 19 May 2017 12:22:08 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1dBe6p-0008u7-S6; Fri, 19 May 2017 12:22:08 +0300 Subject: Re: iMC SMBus controller driver To: Ravi Pokala , "freebsd-hackers@freebsd.org" References: From: Andriy Gapon Message-ID: <532facb6-00bb-52d2-3e99-4e8c1bc16670@FreeBSD.org> Date: Fri, 19 May 2017 12:21:11 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.1.0 MIME-Version: 1.0 In-Reply-To: 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.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 May 2017 09:22:11 -0000 On 19/05/2017 00:22, Ravi Pokala wrote: > Hi folks, > > In recent years, Intel has put an SMBus controller on the CPU's integrated Memory Controller (iMC). Does anyone have a driver for that? Even if it's not something that you're willing to open up, just knowing that someone has done it would be nice. > > (I'm specifically interested in Haswell/Broadwell Xeon, but I'd imagine the programming model is the same for the iMC/SMBus controller on all the recent CPUs.) Could ismt be what you are looking for? -- Andriy Gapon From owner-freebsd-hackers@freebsd.org Fri May 19 13:00: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 2A7C7D72E9F for ; Fri, 19 May 2017 13:00:36 +0000 (UTC) (envelope-from sebastian.huber@embedded-brains.de) Received: from dedi548.your-server.de (dedi548.your-server.de [85.10.215.148]) (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 DF573155A for ; Fri, 19 May 2017 13:00:34 +0000 (UTC) (envelope-from sebastian.huber@embedded-brains.de) Received: from [88.198.220.130] (helo=sslproxy01.your-server.de) by dedi548.your-server.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.85_2) (envelope-from ) id 1dBhWC-00014v-Fu for freebsd-hackers@freebsd.org; Fri, 19 May 2017 15:00:32 +0200 Received: from [82.135.62.35] (helo=mail.embedded-brains.de) by sslproxy01.your-server.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1dBhWC-0005oI-7Q for freebsd-hackers@freebsd.org; Fri, 19 May 2017 15:00:32 +0200 Received: from localhost (localhost.localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id 99F732A003F for ; Fri, 19 May 2017 15:01:08 +0200 (CEST) Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id ikBF_njeu4v8 for ; Fri, 19 May 2017 15:01:08 +0200 (CEST) Received: from localhost (localhost.localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id 1480C2A160A for ; Fri, 19 May 2017 15:01:08 +0200 (CEST) X-Virus-Scanned: amavisd-new at zimbra.eb.localhost Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id uxU_lqcAWWHy for ; Fri, 19 May 2017 15:01:08 +0200 (CEST) Received: from huber-linux.eb.localhost (unknown [192.168.96.129]) by mail.embedded-brains.de (Postfix) with ESMTP id 03C392A003F for ; Fri, 19 May 2017 15:01:08 +0200 (CEST) From: Sebastian Huber To: freebsd-hackers@freebsd.org Subject: [PATCH] bitset(9): Add some operations Date: Fri, 19 May 2017 15:00:30 +0200 Message-Id: <1495198830-10573-1-git-send-email-sebastian.huber@embedded-brains.de> X-Mailer: git-send-email 1.8.4.5 X-Authenticated-Sender: smtp-embedded@poldinet.de X-Virus-Scanned: Clear (ClamAV 0.99.2/23398/Fri May 19 10:59:52 2017) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 May 2017 13:00:36 -0000 Add BIT_OR2(), BIT_AND2(), BIT_NAND2(), BIT_XOR() and BIT_XOR2(). --- share/man/man9/bitset.9 | 91 +++++++++++++++++++++++++++++++++++++++++++++++++ sys/sys/bitset.h | 30 ++++++++++++++++ 2 files changed, 121 insertions(+) diff --git a/share/man/man9/bitset.9 b/share/man/man9/bitset.9 index ef55115..4842225 100644 --- a/share/man/man9/bitset.9 +++ b/share/man/man9/bitset.9 @@ -48,8 +48,13 @@ .Nm BIT_OVERLAP , .Nm BIT_CMP , .Nm BIT_OR , +.Nm BIT_OR2 , .Nm BIT_AND , +.Nm BIT_AND2 , .Nm BIT_NAND , +.Nm BIT_NAND2 , +.Nm BIT_XOR , +.Nm BIT_XOR2 , .Nm BIT_CLR_ATOMIC , .Nm BIT_SET_ATOMIC , .Nm BIT_SET_ATOMIC_ACQ , @@ -95,8 +100,13 @@ .Fa "const SETSIZE" "struct STRUCTNAME *bitset1" "struct STRUCTNAME *bitset2" .Fc .Fn BIT_OR "const SETSIZE" "struct STRUCTNAME *dst" "struct STRUCTNAME *src" +.Fn BIT_OR2 "const SETSIZE" "struct STRUCTNAME *dst" "struct STRUCTNAME *src1" "struct STRUCTNAME *src2" .Fn BIT_AND "const SETSIZE" "struct STRUCTNAME *dst" "struct STRUCTNAME *src" +.Fn BIT_AND2 "const SETSIZE" "struct STRUCTNAME *dst" "struct STRUCTNAME *src1" "struct STRUCTNAME *src2" .Fn BIT_NAND "const SETSIZE" "struct STRUCTNAME *dst" "struct STRUCTNAME *src" +.Fn BIT_NAND2 "const SETSIZE" "struct STRUCTNAME *dst" "struct STRUCTNAME *src1" "struct STRUCTNAME *src2" +.Fn BIT_XOR "const SETSIZE" "struct STRUCTNAME *dst" "struct STRUCTNAME *src" +.Fn BIT_XOR2 "const SETSIZE" "struct STRUCTNAME *dst" "struct STRUCTNAME *src1" "struct STRUCTNAME *src2" .\" .Fn BIT_CLR_ATOMIC "const SETSIZE" "size_t bit" "struct STRUCTNAME *bitset" .Fn BIT_SET_ATOMIC "const SETSIZE" "size_t bit" "struct STRUCTNAME *bitset" @@ -312,6 +322,23 @@ is composed of multiple machine words, performs multiple individually atomic operations.) .Pp The +.Fn BIT_OR2 +macro computes +.Fa src1 +bitwise or +.Fa src2 +and assigns the result to +.Fa dst . +(It is the +.Nm +equivalent of the scalar: +.Fa dst += +.Fa src1 +| +.Fa src2 . ) +.Pp +The .Fn BIT_AND macro clears bits absent from .Fa src @@ -328,6 +355,23 @@ is similar, with the same atomic semantics as .Fn BIT_OR_ATOMIC . .Pp The +.Fn BIT_AND2 +macro computes +.Fa src1 +bitwise and +.Fa src2 +and assigns the result to +.Fa dst . +(It is the +.Nm +equivalent of the scalar: +.Fa dst += +.Fa src1 +& +.Fa src2 . ) +.Pp +The .Fn BIT_NAND macro clears bits set in .Fa src @@ -339,6 +383,53 @@ equivalent of the scalar: .Fa dst &= .Fa ~ src . ) +.Pp +The +.Fn BIT_NAND2 +macro computes +.Fa src1 +bitwise and not +.Fa src2 +and assigns the result to +.Fa dst . +(It is the +.Nm +equivalent of the scalar: +.Fa dst += +.Fa src1 +& ~ +.Fa src2 . ) +.Pp +The +.Fn BIT_XOR +macro toggles bits set in +.Fa src +in +.Fa dst . +(It is the +.Nm +equivalent of the scalar: +.Fa dst +^= +.Fa src . ) +.Pp +The +.Fn BIT_XOR2 +macro computes +.Fa src1 +bitwise exclusive or +.Fa src2 +and assigns the result to +.Fa dst . +(It is the +.Nm +equivalent of the scalar: +.Fa dst += +.Fa src1 +^ +.Fa src2 . ) .Sh BITSET_T_INITIALIZER EXAMPLE .Bd -literal BITSET_DEFINE(_myset, MYSETSIZE); diff --git a/sys/sys/bitset.h b/sys/sys/bitset.h index 723c39b..8bc9e3d 100644 --- a/sys/sys/bitset.h +++ b/sys/sys/bitset.h @@ -122,18 +122,48 @@ (d)->__bits[__i] |= (s)->__bits[__i]; \ } while (0) +#define BIT_OR2(_s, d, s1, s2) do { \ + __size_t __i; \ + for (__i = 0; __i < __bitset_words((_s)); __i++) \ + (d)->__bits[__i] = (s1)->__bits[__i] | (s2)->__bits[__i];\ +} while (0) + #define BIT_AND(_s, d, s) do { \ __size_t __i; \ for (__i = 0; __i < __bitset_words((_s)); __i++) \ (d)->__bits[__i] &= (s)->__bits[__i]; \ } while (0) +#define BIT_AND2(_s, d, s1, s2) do { \ + __size_t __i; \ + for (__i = 0; __i < __bitset_words((_s)); __i++) \ + (d)->__bits[__i] = (s1)->__bits[__i] & (s2)->__bits[__i];\ +} while (0) + #define BIT_NAND(_s, d, s) do { \ __size_t __i; \ for (__i = 0; __i < __bitset_words((_s)); __i++) \ (d)->__bits[__i] &= ~(s)->__bits[__i]; \ } while (0) +#define BIT_NAND2(_s, d, s1, s2) do { \ + __size_t __i; \ + for (__i = 0; __i < __bitset_words((_s)); __i++) \ + (d)->__bits[__i] = (s1)->__bits[__i] & ~(s2)->__bits[__i];\ +} while (0) + +#define BIT_XOR(_s, d, s) do { \ + __size_t __i; \ + for (__i = 0; __i < __bitset_words((_s)); __i++) \ + (d)->__bits[__i] ^= (s)->__bits[__i]; \ +} while (0) + +#define BIT_XOR2(_s, d, s1, s2) do { \ + __size_t __i; \ + for (__i = 0; __i < __bitset_words((_s)); __i++) \ + (d)->__bits[__i] = (s1)->__bits[__i] ^ (s2)->__bits[__i];\ +} while (0) + #define BIT_CLR_ATOMIC(_s, n, p) \ atomic_clear_long(&(p)->__bits[__bitset_word(_s, n)], \ __bitset_mask((_s), n)) -- 1.8.4.5 From owner-freebsd-hackers@freebsd.org Fri May 19 16:00: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 1175DD7313A for ; Fri, 19 May 2017 16:00:13 +0000 (UTC) (envelope-from rpokala@mac.com) Received: from mr11p00im-asmtp002.me.com (mr11p00im-asmtp002.me.com [17.110.69.253]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EBE2B7D5; Fri, 19 May 2017 16:00:12 +0000 (UTC) (envelope-from rpokala@mac.com) Received: from process-dkim-sign-daemon.mr11p00im-asmtp002.me.com by mr11p00im-asmtp002.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) id <0OQ700D00FMHZG00@mr11p00im-asmtp002.me.com>; Fri, 19 May 2017 15:00:06 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mac.com; s=4d515a; t=1495206006; bh=/ZBAL3AbgIJg785SsY4duuZs6WcxIdsyQMZMLPe9L0I=; h=Date:Subject:From:To:Message-id:MIME-version:Content-type; b=MDTDn7YnjrxsktVoV1bVjKaTSZPcsPgprTt+di5IvpUtkywoedsnTVjonOgabYNXs Xu/vWNjK6zeGovYXh5xtGCIaNUHAIXB0Qv8PmcnksDgQ2z3kNBk/DGIgOnawaDUD8l xuMgG5v3Co3/Oej5smGc5y1a7EJDLR1Z5p62Di/KpWcKUXpxmYOCojtpQxsy0j8aKc To3KF1OMAt7G1q+Cj6cHV0PE/Q+LDCWmYhtmeAQg9f55RQp98Zq1p27HiFAXanpE5i Tl7Mb0PQ//IEOD0JXgzVThdrM0+44/DyJmbd2nYzysRm33Z8a5BTPsbUYZ7+W0mHk2 3ESCyzPJo/pAA== Received: from icloud.com ([127.0.0.1]) by mr11p00im-asmtp002.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) with ESMTPSA id <0OQ7002EUGC2O530@mr11p00im-asmtp002.me.com>; Fri, 19 May 2017 15:00:03 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-05-19_09:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1034 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1701120000 definitions=main-1705190094 User-Agent: Microsoft-MacOutlook/f.21.0.170409 Date: Fri, 19 May 2017 08:00:01 -0700 Subject: Re: iMC SMBus controller driver From: Ravi Pokala To: Andriy Gapon , "freebsd-hackers@freebsd.org" Message-id: <2428158C-45B3-434A-A2FD-B24A655C7564@panasas.com> Thread-topic: iMC SMBus controller driver References: <532facb6-00bb-52d2-3e99-4e8c1bc16670@FreeBSD.org> In-reply-to: <532facb6-00bb-52d2-3e99-4e8c1bc16670@FreeBSD.org> MIME-version: 1.0 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: 7bit X-Mailman-Approved-At: Fri, 19 May 2017 17:32:34 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 May 2017 16:00:13 -0000 -----Original Message----- > From: Andriy Gapon > Date: 2017-05-19, Friday at 02:21 > To: Ravi Pokala , "freebsd-hackers@freebsd.org" > Subject: Re: iMC SMBus controller driver > > On 19/05/2017 00:22, Ravi Pokala wrote: >> Hi folks, >> >> In recent years, Intel has put an SMBus controller on the CPU's integrated Memory Controller (iMC). Does anyone have a driver for that? Even if it's not something that you're willing to open up, just knowing that someone has done it would be nice. >> >> (I'm specifically interested in Haswell/Broadwell Xeon, but I'd imagine the programming model is the same for the iMC/SMBus controller on all the recent CPUs.) > > Could ismt be what you are looking for? Yes and no. ismt(4) is a non-ichsmb SMBus controller, but the driver only supports Atom S1200 (Briarwood) and Atom C2000 (Avoton / Rangeley) SoCs. But maybe it just needs to have newer devices added to the list...? As it happens, I have the datasheet for the Rangeley at my fingertips. I searched for some of the magic numbers from ismt(4), and found where the "SMT" SMBus controller (PCI 0:13:0) is documented. I also did some digging on Intel's site, and found Volume 2 of the Broadwell Xeon datasheet, where the iMC (PCI 0:19:0 and 0:22:0) is documented. Unfortunately, Rangeley's SMT SMBus controller and Broadwell's iMC's SMBus controller bear no resemblance to each other. So, no, ismt(4) is not the droid ^W driver I'm looking for. :-/ Thanks, Ravi (rpokala@) > -- > Andriy Gapon From owner-freebsd-hackers@freebsd.org Fri May 19 20:20: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 D24E6D747D4 for ; Fri, 19 May 2017 20:20:04 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citapm.icyb.net.ua (citapm.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 2805B1FAC for ; Fri, 19 May 2017 20:20:03 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citapm.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id XAA15781; Fri, 19 May 2017 23:19:55 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1dBoNP-0009Py-Ls; Fri, 19 May 2017 23:19:55 +0300 Subject: Re: iMC SMBus controller driver To: Ravi Pokala , "freebsd-hackers@freebsd.org" References: <532facb6-00bb-52d2-3e99-4e8c1bc16670@FreeBSD.org> <2428158C-45B3-434A-A2FD-B24A655C7564@panasas.com> From: Andriy Gapon Message-ID: Date: Fri, 19 May 2017 23:18:59 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.1.0 MIME-Version: 1.0 In-Reply-To: <2428158C-45B3-434A-A2FD-B24A655C7564@panasas.com> 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.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 May 2017 20:20:04 -0000 On 19/05/2017 18:00, Ravi Pokala wrote: > Yes and no. ismt(4) is a non-ichsmb SMBus controller, but the driver only supports Atom S1200 (Briarwood) and Atom C2000 (Avoton / Rangeley) SoCs. But maybe it just needs to have newer devices added to the list...? > > As it happens, I have the datasheet for the Rangeley at my fingertips. I searched for some of the magic numbers from ismt(4), and found where the "SMT" SMBus controller (PCI 0:13:0) is documented. I also did some digging on Intel's site, and found Volume 2 of the Broadwell Xeon datasheet, where the iMC (PCI 0:19:0 and 0:22:0) is documented. Unfortunately, Rangeley's SMT SMBus controller and Broadwell's iMC's SMBus controller bear no resemblance to each other. > > So, no, ismt(4) is not the droid ^W driver I'm looking for. :-/ Oh, I see now. It's quite a specialized controller for talking to things on DIMMs. The interface is quite different from any other controller, but it is very simple, because of the limited functionality it provides. So, it shouldn't be hard to write a driver for it. I found this submission for a Linux driver, but not sure if it was committed: http://lm-sensors.lm-sensors.narkive.com/Xy87Q8tj/patch-v3-0-4-imc-smbus-tsod-hwmon-devices-and-eeprom-modalias -- Andriy Gapon From owner-freebsd-hackers@freebsd.org Sat May 20 11:52: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 3E9BED76595 for ; Sat, 20 May 2017 11:52:27 +0000 (UTC) (envelope-from bapt@FreeBSD.org) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 2DE701251 for ; Sat, 20 May 2017 11:52:27 +0000 (UTC) (envelope-from bapt@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id 2D499D76594; Sat, 20 May 2017 11:52:27 +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 2CEA5D76593 for ; Sat, 20 May 2017 11:52:27 +0000 (UTC) (envelope-from bapt@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0FBA11250 for ; Sat, 20 May 2017 11:52:27 +0000 (UTC) (envelope-from bapt@FreeBSD.org) Received: by freefall.freebsd.org (Postfix, from userid 1235) id 2E08A642D; Sat, 20 May 2017 11:52:26 +0000 (UTC) Date: Sat, 20 May 2017 13:52:25 +0200 From: Baptiste Daroussin To: hackers@FreeBSD.org Subject: pxe/efi loader rootpath protocols Message-ID: <20170520115225.chsy4phzznik6ow4@ivaldir.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="uul3ndhmpsguhdav" Content-Disposition: inline User-Agent: NeoMutt/20170428 (1.8.2) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 May 2017 11:52:27 -0000 --uul3ndhmpsguhdav Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi all, In FreeBSD current some changes happened in the loader regarding pxeboot/loader.efi when pxe booting. The goal is to be able to support natively multiple protocols (at first: nfs, tftpfs) in the future http. After having gone some hackish way to avoid problem with chainloading with iPxe chainloading (which I will explain below) I want to move to a proper way. currently in releases if one passes via dhcp root-path ip:path the pxeloader will try look for a nfsroot on the nfs server under the path if one set root-path path the loader will look for a nfsroot under on the nfs server located on the same machine the pxeboot was loader from via tftp To activate the support for tftpfs by default in the loader, I looked for a way to be able to specify the protocol in the dhcp request. The natural direction would have been to add the protocol scheme in the root-path tftp://ip/path and add a new nfs://ip/path Extending the current supported list of root-path (aka not breaking existing setup). While it looked good, I quickly found a problem: chainloading from ipxe which is for example the default for net booting from qemu in bios mode. ipxe already expect a scheme:/ and knows about tftp:/ but expect something else so it will not load the pxeboot but try to boot directly from tftp:/ So I tried to workaround it by not changing the root-path but abusing a dhcp option that defined a tftpserver to specify to the pxeboot it needs to use tftpfs and not nfs. While it worked, not all dhcp servers supports that, and that is still a problem for the day we add http support. The new approach I would like to go with it having a proper URI parser in libstand for pxeboot/loader.efi to use and ignore the issue with iPXE. Tell the people to configure properly their dhcp server (iPXE is provide a user-class information IPXEBOOT) so the dhcp servers can avoid sending root-path to iPXE for machines supposed to boot on pxeboot. The loader issueing a dhcp request itself it will get the proper root-path and will do the right thing. If you see any problem with this approach please tell it quickly. I want to go fast as I want it in FreeBSD 11.1 I will issue a review soon Best regards, Bapt --uul3ndhmpsguhdav Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEgOTj3suS2urGXVU3Y4mL3PG3PloFAlkgLfcACgkQY4mL3PG3 Plo3bg//eQNA8Gkn/DV8CCXTVMDrablaBoZUBGHPxVSmLCnTpuLrm+TO31M0H/VP REZGrTeCv0bhjvo9mX50PhEVJVYJXBBtD4ZZohKa9oEJOv8eywcm9ThR/kHV1C49 gSzFFDavWDSVtZtUBztty5M0slOZ4Y6MBYvpn+tUfjuY1uYJ58lIS+X7+4TaMyeU m0qAOuBbHX9anCvHV/GadwippmJVRBgW6Dim5K65Jjwmga7WEzo8XHMW2/9Sg/Bq WtGPY617Fe4wlzwGmyBUnn9LVAIXL7tKGjIPE1IKnEUVv0VCuJsavvjDJU/vwvBW QXYuLCVj0yw1NihnkNZH85w931aZkwSF5lrhUSsG/iz+5U5/5UfpwJGAX5A2HbLF 8dtGX87tYmQChq1xZPxlRM35OJggGKqeUrxrXCFqZyIm+wJuCqNFl+bQcQpOwKIW SK0TU3gkdIrjklZQK4VUzHL0k+eZRqqCPGpGzPBQNHJ9ObXjxcfMhkz1Nn/6klqT Q1vrNvwb+RJG2yuh/cDfClo5RsOs9alUnjI9tmw8c361dPpzbYZgAESUh4Eu3krh gPDN4d/pi5+SJEvKGFVMPYzncoIhWF/pPlLvJjDI+jYq8wFGUYZ+Gl+dKzjZp1CM tC+OizeYblZIBXgSdKkvzc+qz4VbtFoTiOFwjgM1UdvQoaX1b14= =B8Xe -----END PGP SIGNATURE----- --uul3ndhmpsguhdav--