daily CVS update output
Updating src tree: P src/lib/librumpuser/rumpuser_sp.c P src/share/man/man9/cprng.9 P src/share/mk/bsd.README P src/sys/arch/arm/sociox/if_ave.c P src/sys/arch/arm/sociox/if_scx.c P src/sys/arch/arm/sociox/sni_gpio.c P src/sys/arch/arm/sunxi/files.sunxi P src/sys/arch/evbarm/conf/MMNET_GENERIC P src/sys/arch/hpcarm/conf/NETBOOKPRO P src/sys/arch/hpcarm/conf/WZERO3 P src/sys/arch/x86/pci/if_vmx.c P src/sys/dev/fdt/files.fdt P src/sys/dev/ic/spdmem.c P src/sys/dev/ic/spdmemvar.h P src/sys/dev/pci/if_kse.c P src/sys/dev/pci/pucdata.c P src/sys/dev/usb/if_umb.c P src/sys/dev/usb/vhci.c P src/sys/kern/kern_sleepq.c P src/sys/net/if_bridge.c Updating xsrc tree: Killing core files: Updating release-8 src tree (netbsd-8): U doc/CHANGES-8.2 P etc/etc.amiga/Makefile.inc P sys/external/bsd/drm2/dist/drm/radeon/radeon_vce.c Updating release-8 xsrc tree (netbsd-8): Updating release-9 src tree (netbsd-9): U doc/CHANGES-9.1 P etc/etc.amiga/Makefile.inc P sys/arch/vax/vsa/ncr.c Updating release-9 xsrc tree (netbsd-9): Updating file list: -rw-rw-r-- 1 srcmastr netbsd 39589360 Mar 25 03:11 ls-lRA.gz
Re: Issue 8 POSIX changes coming
Date:Mon, 23 Mar 2020 19:16:36 +0100 From:Joerg Sonnenberger Message-ID: <20200323181636.ga123...@bec.de> | We have _l versions of every function that depends on the (global) | locale. That's good to know - I don't often venture near the libc internals. It is even better to actually have. | It's a lot of busy work to add them to the various man pages... Understood - but not really just "busy work" - without the doc, most users wouldn't even think to look for them (or at least, I didn't...) and the work required for everyone to discover the correct arg sequence (especially for the multi-suffix functions) by hunting down the protypes will soon outweigh the one time effort to add things in the manuals. Over time, we should look to adding all of them, which I will start by adding strerror_l and strerror_lr to strerror(3) (and then perhaps the strftime _l functions as well). kre
Re: Issue 8 POSIX changes coming
Incidentally, is there a reason that strerror_lr is not exposed to userland, it has no prototype (not even one guarded by _NETBSD_SOURCE) anywhere in /usr/include/* and there's actually no alias for it (all that actually exists is the internal _strerror_lr name). That violates your "We have _l versions of every function that depends on the (global) locale" doesn't it? strerror_r depends upon the global locale, yet it appears that we don't actually have an _l version of that one. Is this really intended only as an internal libc function (the one that actually does all the real work for all the strerror*() functions) or is it intended for users to be able to use that as well? [If it matters, I vote for the latter interpretation.] It seems like to expose it, all we need is a weak_alias() in strerror_r.c and a prototype in (and doc...) Also, can someone explain strerror_ss() and strerror_r_ss() - which look to be implementations of the ancient (pre locale) strerror() functions, and as best I can see, exist solely for the purposes of jemalloc() ? They are exposed in libc, but have no prototypes - and I assume should not be used without a very good reason, and hence not be documented either. kre ps: I'm going to hold off on the promised man page update until this is resolved, so it can document all (but only) what we actually provide.
VIA Padlock on AMD64
Hi, I accidentally noticed that padlock engine is not included on AMD64 port (neither as module or built-in). Is there any reason it excluded from it? The build currently fails because inline asm code is using pushl, popl instructions in the code in via_padlock_cbc method, but replacing them with pushf, popf seemingly fixes the build and padlock attaches. Since VIA has x86-64 based CPUs and all of them has the engine, probably it makes sense to include it? Regards, Andrius V
Re: Issue 8 POSIX changes coming
On Tue, Mar 24, 2020 at 02:27:54PM +0700, Robert Elz wrote: > Incidentally, is there a reason that strerror_lr is not exposed to > userland, it has no prototype (not even one guarded by _NETBSD_SOURCE) > anywhere in /usr/include/* and there's actually no alias for it > (all that actually exists is the internal _strerror_lr name). > > That violates your "We have _l versions of every function that depends > on the (global) locale" doesn't it? strerror_r depends upon the > global locale, yet it appears that we don't actually have an _l version > of that one. > > Is this really intended only as an internal libc function (the one that > actually does all the real work for all the strerror*() functions) > or is it intended for users to be able to use that as well? > > [If it matters, I vote for the latter interpretation.] > > It seems like to expose it, all we need is a weak_alias() in strerror_r.c > and a prototype in (and doc...) Yes, so far it has been intended only for internal use as strerror_l has been in discussion as recommented public interface for a long time. So strerror_l really is the locale-specific variant of strerror_r. > Also, can someone explain strerror_ss() and strerror_r_ss() - which look > to be implementations of the ancient (pre locale) strerror() functions, and > as best I can see, exist solely for the purposes of jemalloc() ? > They are exposed in libc, but have no prototypes - and I assume should > not be used without a very good reason, and hence not be documented either. They are for internal use only. They are meant for situations where you can't allocate memory and don't really care that much about the one situation were they can be racy (new/unknown error). Joerg
Re: Issue 8 POSIX changes coming
On Tue, Mar 24, 2020 at 09:27:54PM +0700, Robert Elz wrote:
> Date:Tue, 24 Mar 2020 14:13:30 +0100
> From:Joerg Sonnenberger
> Message-ID: <20200324131330.ga60...@bec.de>
>
> | Yes, so far it has been intended only for internal use as strerror_l has
> | been in discussion as recommented public interface for a long time. So
> | strerror_l really is the locale-specific variant of strerror_r.
>
> It is really the locale-specific, and thread safe, version of strerror().
strerror is already thread-safe. There is the question on whether we
should avoid copying internally for the common case, but that's a minor
optimisation at best.
> That some people believe the only use for strerror_r() is as a thread safe
> variant of strerror() is unfortunate, but it also allows multiple error
> numbers to be translated at once, in code something like
>
> if ((fd = open(path, whatever)) < 0) {
> err1 = errno;
> if (fd = open(path, O_CREAT|whatever)) < 0)) {
> err2 = errno;
> strerror_r(err1, ebuf1, sizeof ebuf1);
> strerror_r(err2, ebuf2, sizeof ebuf2);
> fprintf(stderr, "%s: open failed: %s,\n"
> "%.*s create also failed: %s\n",
> path, ebuf1, ebuf2, stelen(path), "");
> return -1;
> }
> }
>
> which strerror_l() can only handle by doing a strcpy() of its result
> into a local buffer, which is annoying (putting a wrapper around strerror_r
> to have it return the buffer would allow the whole thing to be made args
> to fprintf, which would make it even simpler to use - more akin to
> strerror() or strerror_l() from that perspective - but that's trivial for
> any app that needs it to do for itself).
I am aware of that. But it is rare enough that it doesn't seem to
justify having a second interface. It also seems to be a
micro-optimisation at best.
On the const front: I've mostly given up on const correctness of return
values in C...
Joerg
Re: Issue 8 POSIX changes coming
On 24.03.2020 15:27, Robert Elz wrote: > Are there any objections to making strerror_lr() user visible? There are no users. Our strerror() is already thread-safe. signature.asc Description: OpenPGP digital signature
Re: Issue 8 POSIX changes coming
Date:Tue, 24 Mar 2020 15:48:07 +0100 From:Joerg Sonnenberger Message-ID: <20200324144807.ga63...@bec.de> | strerror is already thread-safe. Ours is, I know, but assuming that isn't portable, it isn't promised, and some implementations are not. (My man page changes say all of that already). | There is the question on whether we should avoid copying internally | for the common case, but that's a minor optimisation at best. Not a current concern anyway - how the functions are implemented is a whole different issue. But in that area, I am not much enamoured with the way that strerror(-1) currently returns (POSIX locale) "Unknown error: 4294967295" all in the name of "cute" coding, and I might fix that sometime. | I am aware of that. But it is rare enough that it doesn't seem to | justify having a second interface. And having _l variants for *all* functions which use the global locale isn't either? | It also seems to be a micro-optimisation at best. More like it provides consistency. But for now, I think I'll (mostly) just comment out the strerror_lr() parts I added to the man page, leave it there for possible future use, and (perhaps tomorrow, no, that's actually later today, here) commit the rest of what I have. | On the const front: I've mostly given up on const correctness of return | values in C... There are times it matters (it really did once for our strerror()) but for this one now, it seems unnecessarily pedantic, given that the standard defined interface doesn't include it. So I think I'll just delete that paragraph as well, in a separate commit, so it is easy to revert if desired later. kre
Re: Build time measurements
Hi Andreas. On Mon, Mar 23, 2020 at 04:11:17PM +0200, Andreas Gustafsson wrote: > In September and November, I reported some measurements of the amount > of system time it takes to build a NetBSD-8/amd64 release on different > versions of -current/amd64. I have now repeated the measurements with > a couple of newer versions of -current on the same hardware, and here > are the results. The left column is the source date of the -current > system hosting the build. > > HP ProLiant DL360 G7, 2 x Xeon L5630, 8 cores, 32 GB, build.sh -j 8 > > 2016.09.06.06.27.173930.86 real 15737.04 user 4245.26 sys > 2019.10.18.17.16.504461.47 real 16687.37 user 9344.68 sys > 2020.03.17.22.03.414723.81 real 16646.42 user 8928.72 sys > 2020.03.22.19.56.074595.95 real 16592.80 user 8171.56 sys > > I also measured the same versions on a newer machine with more cores: > > Dell PowerEdge 630, 2 x Xeon E5-2678 v3, 24 cores, 32 GB, build.sh -j 24 > > 2016.09.06.06.27.173321.55 real 9853.49 user 5156.92 sys > 2019.10.18.17.16.503767.63 real 10376.15 user 16100.99 sys > 2020.03.17.22.03.412910.76 real 9696.10 user 18367.58 sys > 2020.03.22.19.56.072711.14 real 9729.10 user 12068.90 sys Thank you for doing this, and for bisecting the performance losses over time (I fixed the vnode regression you found BTW). There are two options enabled in -current that spoil performance on multi processor machines: DIAGNOSTIC and acpicpu. I'm guessing that you had both enabled during your test runs. We ship releases without DIAGNOSTIC, and acpicpu really needs to be fixed. I did some "build.sh release" runs on a machine vaguely similar in spec to you second one, a ThinkStation D30 with 2x Xeon E5-2696 v2. DIAGNOSTIC and acpicpu are disabled in all kernels but they are otherwise GENERIC. The 2020-04-?? kernel is HEAD plus the remaining changes from the ad-namecache branch. A Linux result is included too for a reference point. I would have tried FreeBSD as well, but don't have it installed on this machine yet. Andrew HT disabled in BIOS so -j24: 2019-10-23 2445.46 real 17297.90 user 16725.01 sys 2020-01-16 2013.58 real 16772.79 user 7801.39 sys 2020-03-23 1850.98 real 16383.89 user 4777.89 sys 2020-04-?? 1791.62 real 16367.51 user 3662.62 sys Linux 5.4.191688.29 real 15682.22 user 1962.81 sys HT enabled so -j48. With percentage real time reduction thanks to HT: 2019-10-23 -5% 2583.56 real 24459.69 user 45719.70 sys 2020-01-16 0% 2023.79 real 24495.20 user 20431.37 sys 2020-03-23 5% 1765.39 real 24348.67 user 8856.36 sys 2020-04-?? 7% 1672.71 real 24770.28 user .92 sys Linux 5.4.193% 1644.41 real 24425.07 user 2926.18 sys
