Re: PTHREAD_STACK_MIN support

On Wed, Jun 08, 2016 at 09:13:57AM +0200, Kamil Rytarowski wrote: > The point is to abstract this work to determine minimal stack size from > 3rd party software. That's an argument for providing the sysconf, but not for the static limit. Joerg

Re: pthread library related

On Mon, May 30, 2016 at 02:19:26PM -0700, Charles Cui wrote: > good to know atomic_inc_uint_nv is implemented using cas. No, atomic_inc is *not* necessarily implemented using CAS. There are a couple of different ways to do it ranging from implicit serialisation on UP-only systems over CAS/LL-SC

Re: pthread library related

On Thu, Jun 23, 2016 at 03:33:08PM +, Christos Zoulas wrote: > In article <20160520091545.ga30...@britannica.bec.de>, > Joerg Sonnenberger <jo...@bec.de> wrote: > >On Thu, May 19, 2016 at 01:36:29PM -0400, Christos Zoulas wrote: > >> You can see how FreeBSD

Re: PTHREAD_STACK_MIN support

On Thu, Jun 23, 2016 at 03:29:02PM +, Christos Zoulas wrote: > In article , > Kamil Rytarowski wrote: > >On 08.06.2016 09:09, Martin Husemann wrote: > >> Maybe a minor nit: > >> > >> case _SC_THREAD_STACK_MIN: > >> -

Re: honor to join NetBSD community

On Wed, Apr 27, 2016 at 06:11:28PM -0700, Charles Cui wrote: > 1. I noticed that netbsd community use CVS for version control, I am > familiar with git, and can learn CVS. Also I noticed that there are > actually git repo at github which hosts the netbsd source code, and > seems there is an

Re: refine of the GSOC project

On Thu, May 12, 2016 at 11:13:11PM +0200, Kamil Rytarowski wrote: > An alternative is to go for 8192 (2*PAGE_SIZE) to mimic MINSIGSTKSZ: > > /usr/include/sys/signal.h:#defineMINSIGSTKSZ8192/* > minimum allowable stack */ But it is not 2 * PAGE_SIZE. On some architectures,

Re: pkgin database error

On Sat, May 14, 2016 at 03:50:24PM -0400, James K. Lowden wrote: > I think the pkgin database for fetchmail is wrong atm, at least for > amd64/7.0. I don't know what I can do locally, or where to report > it. Force a refetch? The summary file on the server certainly only contains the entry

Re: zgrep is broken + why is our grep GNU grep by default?

On Fri, May 13, 2016 at 01:25:56AM +0200, Timo Buhrmester wrote: > There are probably other issues with it, I have stopped investigating > as soon as I noticed that despite having what appears to be FreeBSD's > grep in usr.bin/grep, which even supports being run as zgrep, we > default to build our

Re: CVS commit: pkgsrc/devel/atkmm

On Thu, Apr 21, 2016 at 11:13:24AM +0200, Thomas Klausner wrote: > We should really fix NetBSD's tar to handle long file names better... MKBSDTAR=yes, problem solved. Joerg

Re: refine of the GSOC project

On Sun, May 08, 2016 at 12:14:57PM -0700, Charles Cui wrote: > One more thing, I still need to install kernel and userland together, > then reboot. > If I installed kernel and reboot and install userland, it will > promotes me the errors that I send you earlier, but I already compiled > the tools

Re: refine of the GSOC project

On Sun, May 08, 2016 at 03:30:12PM -0400, Christos Zoulas wrote: > On May 8, 12:14pm, charles.cui1...@gmail.com (Charles Cui) wrote: > -- Subject: Re: refine of the GSOC project > > | One more thing, I still need to install kernel and userland together, > | then reboot. > | If I installed kernel

Re: Add a hack to deinstall pthread_atexit handlers at dso unload time

On Wed, Feb 08, 2017 at 05:08:49PM +0100, Martin Husemann wrote: > I would like to adopt a hack like FreeBSD did here: > > https://lists.freebsd.org/pipermail/svn-src-head/2010-August/019849.html > > This allows dynamically loaded shared libraries to install > pthread_atexit handlers. Currently

Re: Add a hack to deinstall pthread_atexit handlers at dso unload time

On Wed, Feb 08, 2017 at 10:31:53PM +0100, Joerg Sonnenberger wrote: > On Wed, Feb 08, 2017 at 05:08:49PM +0100, Martin Husemann wrote: > > I would like to adopt a hack like FreeBSD did here: > > > > https://lists.freebsd.org/pipermail/svn-src-head/2010-August/019849.html

Re: make: order-only prerequisites?

On Sun, Jan 22, 2017 at 06:55:20PM +0100, Edgar Fuß wrote: > > Is there an equivalent in BSD make? > .ORDER? Not the same, but typically a better solution. Order-only dependencies are typically used for things like depends target to simplify the dependency handling. Joerg

Importing mdata-client

Hello, I'd like to import mdata-client into base for simplified creation of Joyent-friendly images. The mdata protocol provides a simple configuration protocol for a KVM/native zone to query optional parameters. It is often use for providing e.g. a ssh authorized_keys file, but can also be used

Re: Calling setlocale() in utilities

On Tue, Sep 20, 2016 at 03:43:23AM +0100, Sevan Janiyan wrote: > I was wondering if there was any reason not to add a call to setlocale > in the utilities we ship in base (I'm thinking of what's in /sbin and > /bin if applicable)? (1) The program can't deal with localised character set etc. (2)

Re: Interface to retrieve LWPs via ptrace(2)

On Tue, Nov 01, 2016 at 03:58:10PM +0100, Kamil Rytarowski wrote: > Which one is preferred for NetBSD? I'd go with neither, but base the new interface on FreeBSD's. PT_GETLWPS takes as argument: struct ptrace_getinfos_request { size_t allocated_lwps; size_t current_lwps; struct

Re: Random build failures (rump)

On Sun, Oct 16, 2016 at 09:39:16PM +, co...@sdf.org wrote: > Interestingly, some stuff within src/lib/librumpuser uses > $RANDOM and assumes that it does what it says, deleting > old content in new supposedly random directory. If it does, it is broken and should be fixed by using mktemp.

Re: Replacing __BEGIN_DECLS in curses

On Wed, Jan 04, 2017 at 02:38:16PM +0100, Thomas Klausner wrote: > On Wed, Jan 04, 2017 at 01:56:21PM +0100, Joerg Sonnenberger wrote: > > On Wed, Jan 04, 2017 at 11:44:03AM +, Roy Marples wrote: > > > One such change is replacing __BEGIN_DECLS and __END_DECLS with expanded

Re: Future shell work - comments reqyuested

On Thu, Jul 13, 2017 at 07:46:39AM +0700, Robert Elz wrote: > ps: I currently have a (self-imposed) moratorium on non-bug-fix sh changes, > so the arithmetic additions mentioned above (and any changes to let/exp, > and -i) will not actually appear for a while. pipefail would be nice :) Joerg

Re: Shipping SSL certificates in the base system

On Sun, Jul 02, 2017 at 05:27:06PM +0100, Benny Siegert wrote: > agc made the argument that including certificates is similar to > including time zone data, which we do. We do not tell users to install > a package to use non-UTC timezones, for instance. The only problem I see is that outdated

Re: adding stuff to the base installation to make user experience better

On Thu, Jul 06, 2017 at 04:54:16PM +0100, Sevan Janiyan wrote: > On 06/07/2017 16:52, Joerg Sonnenberger wrote: > > On Thu, Jul 06, 2017 at 11:23:09AM -0400, Christos Zoulas wrote: > >> 1. A text browser in base. "lynx" or "links" come to mind, I d

Re: Xlocale for NetBSD

On Tue, Apr 25, 2017 at 05:45:14PM -0700, Konrad Schroder wrote: > * Per-thread locale settings This is *not* an advantage. Please read the archives for a longer discussion. Per-thread locales are just insane and ridiculously expensive for no good reason. > * Working LC_COLLATE settings This

Re: change signature of shquotev(3) ?

On Fri, Aug 18, 2017 at 06:46:58AM +0700, Robert Elz wrote: > Currently, shquotev() is declared as ... > > size_t shquotev(int argc, char * const *argv, char *buf, size_t bufsize); This is sadly the canonical way to do it. With C cast rules, you can't win in this case. While C++ allows casts

Re: float128 in libstdc++

On Fri, Jun 23, 2017 at 10:27:40PM +0200, Kamil Rytarowski wrote: > The first solution is being rejected by Joerg on LLVM review as there > might be incomplete support in lib[std]c++. I have no personal > preference which way to go. There is no compiler-rt support for it for i386 at least and

Re: float128 in libstdc++

On Sat, Jun 24, 2017 at 04:03:49PM +0200, Kamil Rytarowski wrote: > NetBSD currently enables it on i386/amd64 and i64. Itanium is currently > without LLVM backend support. ...which is kind of strange given that e.g. SPARC64 uses IEEE 754 128bit long double. Joerg

Re: __STDC_ISO_10646__

On Thu, Jun 01, 2017 at 11:05:01AM -0700, Konrad Schroder wrote: > Is there any particular reason not to implement the requirements for > __STDC_ISO_10646__, that is, to use Unicode UCS for wchar_t? Right now we > use a locale-dependent encoding (and we are not alone in this). Soda-san is

Re: Suggestion: add a "no-stemming" option to apropos(1)?

On Thu, Jun 08, 2017 at 12:51:32PM +0800, Paul Goyette wrote: > I'm continually bitten by the "stemming" that occurs. Today's example > is an attempt to find all the man pages that refer to file system lfs. > Using "apropos lfs" returns more than 120 entries, complete with their > associated

Re: Suggestion: add a "no-stemming" option to apropos(1)?

On Thu, Jun 08, 2017 at 03:43:01PM +0200, Joerg Sonnenberger wrote: > On Thu, Jun 08, 2017 at 12:51:32PM +0800, Paul Goyette wrote: > > I'm continually bitten by the "stemming" that occurs. Today's example > > is an attempt to find all the man pages that refer to f

Re: Deferring variable parse errors in /bin/sh

On Mon, Jun 12, 2017 at 08:48:34AM +0700, Robert Elz wrote: > However, we could do what I see that FreeBSD has done (and when I saw it, > I wondered why) and defer the error message until the expansion actually > happens, rather than when it is parsed (provided we can find some way to > parse the

Re: Printing 64-bit ints

On Thu, Jun 15, 2017 at 01:19:57PM +0100, Robert Swindells wrote: > > Is there a recommended way to print a 64-bit value ? The man page for > printf(3) suggests that using %qd is deprecated. PRI*64. Joerg

Re: removal

On Sun, Jun 11, 2017 at 06:04:12AM +0200, Emmanuel Dreyfus wrote: > Kamil Rytarowski wrote: > > > Every software needing NetBSD content is already broken. > > What about an #error telling to stop including that obsolete file? At > least users hitting the problem will have a clue

Re: Makeing MKBSDTAR=yes the default

On Sat, Sep 09, 2017 at 03:01:14PM +0200, Martin Husemann wrote: > On Sat, Sep 09, 2017 at 02:43:00PM +0200, Kamil Rytarowski wrote: > > No problems are observed except broken sysinst(8) during the process of > > unpacking the sets. I assume that something hardcodes tool arguments and > > they are

Re: pthreads vs. overriden malloc

On Wed, Sep 13, 2017 at 04:48:54PM +0300, Valery Ushakov wrote: > On a typical cpu that would be the alignment of "long double" I guess. > (I haven't checked, but it looks like that's what TINY_MIN_2POW > ensures for "tiny" allocation). Vector registers require 128 or even 256bit alignment. We

Re: Removing header * man page of isinff

On Tue, Sep 26, 2017 at 06:06:44PM +, co...@sdf.org wrote: > Any objections for getting rid of the declaration of isinff and isnanf > in math.h, as well as getting rid of the man page? Yes, it is quite likely going to create more fallout than it helps right now. Just add it to the TODO list

Re: tgmath

On Tue, Sep 26, 2017 at 10:28:23PM +0200, Kamil Rytarowski wrote: > Can we just import as-is the FreeBSD version? It has support for pre-C11 > compilers. This has header to be supported in the clean C99 mode. I see absolutely no reason for wanting to support tgmath.h in pre-C11 mode and a lot of

Re: tgmath

On Tue, Sep 26, 2017 at 11:03:09PM +0200, Kamil Rytarowski wrote: > On 26.09.2017 22:33, Joerg Sonnenberger wrote: > > On Tue, Sep 26, 2017 at 10:28:23PM +0200, Kamil Rytarowski wrote: > >> Can we just import as-is the FreeBSD version? It has support for pre-C11 > >>

libstdc++ and dual ABI

Hello everyone, during the developer summit, I was made aware that we got the fancy dual ABI for libstdc++ with the GCC 5 import. I thought that $#%#$% was disabled from the start, but alas, it isn't. What does dual ABI mean? Long story. std::string in libstdc++ had a performance "feature" for

Re: SYS_sbrk removal proposal

On Tue, Dec 19, 2017 at 11:16:30PM +0100, Kamil Rytarowski wrote: > There is a need for improved debugging facilities to introspect the > jemalloc(3) internals, something comparable to mallinfo from > in GNU. I've never seen a good justification for that. It screams bad complexity to me. Joerg

Re: fmtcheck() query

On Fri, Dec 08, 2017 at 07:15:28PM +0900, Rin Okuyama wrote: > is meaningless in Japanese, which does not distinguish the singular and > plural. However, this kind of matter can not handled in the framework > anyway; how should we do when we do not want the 3rd, but need the 4th > arguments? Use

Re: Changing basename(3) and dirname(3) for future posix compatibility

On Sun, Dec 03, 2017 at 07:57:58AM +0700, Robert Elz wrote: > The next POSIX update (issue 8 of whatever it is called in the wild) - that > is the next "minor corrections" update, as distinct from the next major > update, is planning on (if I follow correctly, has already decided) to > tighten the

Re: Retire message catalog of nvi

On Sat, Dec 02, 2017 at 05:48:03AM +0900, Rin Okuyama wrote: > Messages contain printf(3) format strings. When they are inconsistent > with C sources, a segmentation fault can occur if worse. I found an > inconsistency at least for #038 in ru_RU.KOI8-R.base. Alternatively, check with fmtcheck

Re: getaddrinfo(3) on numerical addresses

On Tue, Oct 24, 2017 at 03:19:29PM +0200, Edgar Fuß wrote: > I've noticed[*] that on NetBSD, getaddrinfo(3) does a resolver lookup even > if presented a numerical address. Is this on purpose? Would it have a > drawback if it would first try to inet_pton() the address? > On Linux, it seems to

Re: getaddrinfo(3) on numerical addresses

On Tue, Oct 24, 2017 at 05:17:19PM +0200, Edgar Fuß wrote: > > That's what AI_NUMERICHOST is for? > No (or so I think). > I would like to save the resolver lookup if we know beforehand we don't need > it. But that's the point of AI_NUMERICHOST. You don't know in advance if it is necessary or

Re: getaddrinfo(3) on numerical addresses

On Tue, Oct 24, 2017 at 10:57:42PM +0700, Robert Elz wrote: > | 3. syntactically correct numerical IPv4 addresses contain digits and dots > > Which is exactly what a domain name can contain. The only reason that > IP addresses (in textual format) are not currently valid domain names, is >

Re: FYI: POSIX update - SIGWINCH and 'struct winsize' (etc) to be added

On Sat, Oct 21, 2017 at 09:20:20AM -0400, Christos Zoulas wrote: > Why don't we unconditionally (not only when _NETBSD_SOURCE) include > from and only make visible struct winsize > when _NETBSD_SOURCE is not defined? Just provide two definitions and protect them with an include guard. No need

Re: hebrew charset encoding iso-8859-8-i

On Thu, Jun 07, 2018 at 05:54:57PM +, co...@sdf.org wrote: > I like to read my email. I don't like needing to use python scripts to > parse it. So this diff worked for me. Are you really sure that they are the same thing? Joerg

Re: sh(1) BUGS entry query

On Mon, Apr 30, 2018 at 08:48:11AM +0700, Robert Elz wrote: > Back in May 2005. dsl@ added this in the BUGS section of sh(1): > > The characters generated by filename completion should probably be quoted > to ensure that the filename is still valid after the input line has been >

Re: failure when building a static-linked emacs25 (-nox11 on amd64)

On Mon, Feb 05, 2018 at 06:24:16PM +, m...@netbsd.org wrote: > This sounds related: > https://v4.freshbsd.org/commit/netbsd/src/ipHBgqsQ9q17WJVz That applies only for dynamic binaries with PIE. Joerg

Re: failure when building a static-linked emacs25 (-nox11 on amd64)

On Mon, Feb 05, 2018 at 08:23:23PM +0100, Joerg Sonnenberger wrote: > On Mon, Feb 05, 2018 at 06:24:16PM +, m...@netbsd.org wrote: > > This sounds related: > > https://v4.freshbsd.org/commit/netbsd/src/ipHBgqsQ9q17WJVz > > That applies only for dynamic binaries wit

Re: Trouble compiling NetBSD: failure in libc

On Wed, Jan 03, 2018 at 10:16:20PM -0800, Eitan Adler wrote: > Hi all, > > When I run ∴./build.sh -m amd64 -U build Do a non-update build. Joerg

Re: Sample based profiling

On Sun, Jul 29, 2018 at 02:45:51PM +0100, Alexander Nasonov wrote: > I wanted to vote for option 3 if we have better tools but devel/gperftools > didn't build on my amd64 boxes (-current and -8): Works for me? Joerg

Re: Sample based profiling

On Thu, Aug 02, 2018 at 09:26:00PM -0400, Thor Lancelot Simon wrote: > On Thu, Aug 02, 2018 at 01:46:35PM +0200, Joerg Sonnenberger wrote: > > On Wed, Aug 01, 2018 at 11:54:10PM -0400, Thor Lancelot Simon wrote: > > > On Tue, Jul 31, 2018 at 08:28:19AM +, Chr

Re: Sample based profiling

On Wed, Aug 01, 2018 at 11:54:10PM -0400, Thor Lancelot Simon wrote: > On Tue, Jul 31, 2018 at 08:28:19AM +, Christos Zoulas wrote: > > In article <2c408f23-6eae-da00-dfb2-ebc7b66e6...@gmx.com>, > > Kamil Rytarowski wrote: > > > > > >I'm for removal of gprof and deduplication of .a files in

Re: swapctl -l

On Wed, Jul 25, 2018 at 12:23:26PM +0200, Edgar Fuß wrote: > It appears to me that swapctl -l lists how much of the swap devices have ever > been in use since they were configured. No? It seems to list exactly how much space is currently in use. Joerg

Sample based profiling

Hello all, the recent work on static PIE support have exposed some fundamental issues in the way profiling support is currently implemented. When -pg is used for linking, the binary will essentially get a copy of libc linked in, but without actually being a static binary. This means that all the

Re: kqueue: intptr vs void *

On Fri, Aug 17, 2018 at 03:16:20PM +0200, Thomas Klausner wrote: > Does anyone know why NetBSD has udata defined as intptr_t in kqueue(3)? It's been discussed over the years. It is supposed to be opaque and pointers don't really qualify for that. I.e. in theory, there are integers that are not

Re: "%m" formatting code and "syslog like"

On Thu, Aug 30, 2018 at 01:11:23PM -0500, Ian Bruene wrote: > > Hello > > I am one of the developers on NTPsec and we are getting warnings on NetBSD > 8.0 in the form: > > ../../ntpd/ntp_io.c:1962:14: warning: %m is only allowed in syslog(3) like > functions [-Wformat=] > > This feature

Re: signed overflow in atan2

On Wed, Mar 07, 2018 at 05:56:21PM +0700, Robert Elz wrote: > Date:Wed, 7 Mar 2018 00:33:04 -0800 > From:Eitan Adler > Message-ID: > > >| I'd like to commit the patch

Re: ld.elf_so compatibility for ancient ELF binaries (pre-2.0)

On Wed, Oct 03, 2018 at 10:40:32PM +0200, Joerg Sonnenberger wrote: > Otherwise I would strictly reduce the compatibility hack to the above > mentioned five architectures. The difference is 132-256 Bytes in .data > and a couple of relocations. The attached patch implements this. Testing

Re: ld.elf_so compatibility for ancient ELF binaries (pre-2.0)

On Thu, Oct 11, 2018 at 07:15:30PM +0200, Joerg Sonnenberger wrote: > On Wed, Oct 03, 2018 at 10:40:32PM +0200, Joerg Sonnenberger wrote: > > Otherwise I would strictly reduce the compatibility hack to the above > > mentioned five architectures. The difference is 132-256

Re: Root device independent bootable disk images

On Wed, Dec 12, 2018 at 05:18:55PM +0200, Andreas Gustafsson wrote: > Since jmcneill's commit of src/lib/libutil/getfsspecname.c 1.5, NetBSD > supports the special string "ROOT." as an alias for the root device in > /etc/fstab. This can be used to avoid hard-coding the device name of > the root

Re: libnv

On Mon, Aug 27, 2018 at 01:39:38AM +0100, Mindaugas Rasiukevicius wrote: > Hi, > > Here is patch to import the FreeBSD's libnv library: > > http://www.netbsd.org/~rmind/libnv.diff I don't think anything has changed since the last time this was discussed, so I consider this a really, really

Re: shell jobs -p

On Thu, Sep 13, 2018 at 02:00:10PM +0200, Edgar Fuß wrote: > The objective was to write s shell script that parallelized invocations of > some command, but only up to a certain number of jobs running in parallel. > There were two ideas to implement this, one using the jobs utility to track > the

Re: Possible slight speedup to non-interactive /bin/sh startup

On Mon, Feb 11, 2019 at 07:36:03PM +0700, Robert Elz wrote: > One assumes that a (much smaller) staticly linked /bin/sh would be > slightly faster still - but doing that isn't really what I think we > should be doing (that option is open to anyone who wants it by > just building a static root

Re: atomics

On Tue, Jun 25, 2019 at 05:06:39PM +0100, Patrick Welche wrote: > Does this mean that the macro is meaningless? Comments? The macros are meaningless. Joerg

Re: Patch to make reentrant by default

On Fri, Apr 26, 2019 at 11:36:00PM +0200, Kamil Rytarowski wrote: > I propose a patch that: Too many different things at once. So the short version of the review: - I don't see any reason for providing unlocked versions of clearerr, feof, ferror or fileno. No reason for inline functions either,

Re: _NETBSD_SOURCE always defined leading to unwanted inclusions

On Sat, Apr 20, 2019 at 10:30:48PM +0200, tlaro...@polynum.com wrote: > A first problem (YMMV) is that can not be included anywhere > but only outside of a block, since there are definitions and not only > declarations. This is just plainly broken. The standard makes no guarantees about any

Re: EV_SET() better C++ compat with alternative implementations

On Tue, Aug 13, 2019 at 08:44:04PM +0200, Kamil Rytarowski wrote: > void* does not prevent storing inside it numbers. While not necessarily relevant in the NetBSD context, this is generally false. Casting random values to a pointer is UB. Joerg

Re: stdbool.h #define bool _Bool

On Wed, Jul 31, 2019 at 08:55:38AM +, co...@sdf.org wrote: > In this case, Mono doesn't include stdbool.h, it's side-loaded for us. > I can avoid the issue with a hack #undef bool, but I'd like to see a > future where Mono works unmodified on unmodified NetBSD, without the use > of hacks.

Re: EV_SET() better C++ compat with alternative implementations

On Sun, Aug 18, 2019 at 05:05:33PM +0200, Kamil Rytarowski wrote: > Ping? Can we switch from intptr_t to void*? Can we just go back to the original state? Joerg

Re: EV_SET() better C++ compat with alternative implementations

On Sun, Aug 18, 2019 at 08:58:15PM -, Valery Ushakov wrote: > Joerg Sonnenberger wrote: > > > On Sun, Aug 18, 2019 at 05:05:33PM +0200, Kamil Rytarowski wrote: > >> Ping? Can we switch from intptr_t to void*? > > > > Can we just go back to the or

Re: EV_SET() better C++ compat with alternative implementations

On Sun, Aug 25, 2019 at 05:12:26PM +0200, Kamil Rytarowski wrote: > I want to see the original state of void* so all casts will be unneded. But it doesn't. Casts are *still* necesseary when using integer indices as data. > Since B lang times we used pointers and integers as the same data type. >

Re: EV_SET() better C++ compat with alternative implementations

On Sun, Aug 25, 2019 at 04:59:41PM +0100, Roy Marples wrote: > On 25/08/2019 16:48, Joerg Sonnenberger wrote: > > On Sun, Aug 25, 2019 at 04:43:51PM +0100, Roy Marples wrote: > > > On 25/08/2019 15:39, Joerg Sonnenberger wrote: > > > > There is no technical re

Re: EV_SET() better C++ compat with alternative implementations

On Sun, Aug 25, 2019 at 04:43:51PM +0100, Roy Marples wrote: > On 25/08/2019 15:39, Joerg Sonnenberger wrote: > > There is no technical reason really for prefering void * > Having to write code to exclusively deal with NetBSD's different API to > compile without warnings sounds lik

Re: Add curses_version() in curses(3)

On Wed, Aug 28, 2019 at 11:00:55AM +0930, Brett Lymn wrote: > I agree with Roy here, if we add the call we should spit out the > version of the curses lib. The ELF version has no meaning though. If anything, keep a date of the last visible interface change. Joerg

Re: Add curses_version() in curses(3)

On Wed, Aug 28, 2019 at 08:59:32PM +0200, Kamil Rytarowski wrote: > On 28.08.2019 14:50, Joerg Sonnenberger wrote: > > On Wed, Aug 28, 2019 at 11:00:55AM +0930, Brett Lymn wrote: > >> I agree with Roy here, if we add the call we should spit out the > >> version of the c

Re: PTHREAD_STACK_MIN vs _SC_THREAD_STACK_MIN

On Sat, Jun 29, 2019 at 06:12:49PM +0200, Kamil Rytarowski wrote: > NetBSD does not implement PTHREAD_STACK_MIN as this is an optional part > of POSIX, however it implements sysconf(_SC_THREAD_STACK_MIN). > > I think that this is inconsistent we we should pick one of the following > paths: > >

Re: dlopen() and -pg

On Tue, Nov 26, 2019 at 03:18:03PM +0100, Manuel Bouyer wrote: > trying to profile a c++ program which uses dlopen and pthreads (opencpn, > FWIW), I'm not surprised at all. -pg will only work reliable with -static. Joerg

Re: dlopen() and -pg

On Tue, Nov 26, 2019 at 04:05:22PM +0100, Manuel Bouyer wrote: > On Tue, Nov 26, 2019 at 03:24:20PM +0100, Joerg Sonnenberger wrote: > > On Tue, Nov 26, 2019 at 03:18:03PM +0100, Manuel Bouyer wrote: > > > trying to profile a c++ program which uses dlopen and pthreads (op

Re: Expose max_align_t unconditionally

On Wed, Feb 26, 2020 at 12:37:06PM +0100, Kamil Rytarowski wrote: > I propose to expose max_align_t unconditionally to C and C++ namespaces. > > It was introduced in C11/C++11, but in practice it is used in C++ code > that formally builds in the C++03/older mode (llvm libc++ expects it >

Re: Expose max_align_t unconditionally

On Wed, Feb 26, 2020 at 02:00:08PM +0100, Michał Górny wrote: > While we're already touching this, I wonder if we should extend it to > cover alignment for AVX types. In particular __m512i requires 512-bit > alignment while our max_align_t currently has 128-bit alignment > on amd64. We do not

Re: Solving the syslogd problem

On Thu, Jan 30, 2020 at 11:50:47AM -0500, Greg Troxel wrote: > Piotr Meyer writes: > > > On Wed, Jan 29, 2020 at 09:32:30PM +, Alexander Nasonov wrote: > > [...] > > > >> I like it when fsck doesn't take ages to check /. With bigger /, > >> it's going to be problematic. > > > > IMVHO moving

Re: Solving the syslogd problem

On Thu, Jan 30, 2020 at 09:29:52AM +0700, Robert Elz wrote: > Date:Wed, 29 Jan 2020 19:33:56 - (UTC) > From:chris...@astron.com (Christos Zoulas) > Message-ID: > > | Having a split /usr makes little sense today though as joerg mentioned, > | even in the

Re: Solving the syslogd problem

On Fri, Jan 31, 2020 at 01:07:21PM +0700, Robert Elz wrote: > | I'm not sure what filesystem attributes you want to apply to / > | that don't also apply to /usr just as well. > > Aside from readonly, which you comment on below (and I will return to > there) there's also the block'frag sizes,

Re: dhcpcd privilege separation user

On Thu, Jan 23, 2020 at 04:38:11PM -0500, Thor Lancelot Simon wrote: > On Thu, Jan 23, 2020 at 09:36:29PM +, Roy Marples wrote: > > Hi List! > > > > dhcpcd-9 is almost ready for release and the big feature for it is privilege > > separation. The question is which system user should it use on

Re: Solving the syslogd problem

On Tue, Jan 28, 2020 at 09:21:23PM +, Roy Marples wrote: > To fix this, I suggest that we split syslogd into syslogd and syslogd-network. We could also do a much simpler and more radical decision and stop splitting / and /usr. Of all the partitioning choices available, it truely seems to be a

Re: LWP private cleanup in headers

On Wed, Dec 25, 2019 at 02:47:45AM +0100, Kamil Rytarowski wrote: > On 25.12.2019 02:45, Kamil Rytarowski wrote: > > 1. or1k + riscv define both __lwp_getprivate_fast() and __lwp_gettcb_fast(). > > > > Is there a point? Unless it is some ABI nit, it looks like a bug to me? > > > > 2. Harmonize

Re: Expose max_align_t unconditionally

On Mon, Mar 09, 2020 at 08:28:58PM +0100, Michał Górny wrote: > To be honest, this is NetBSD-specific problem. Upstream has a fallback > for other platforms but it was explicitly disabled on NetBSD (Kamil or > Joerg will probably know why). No, it is not a NetBSD-specific problem. Guys, please

Re: Expose max_align_t unconditionally

On Mon, Mar 09, 2020 at 01:16:58PM +0100, Kamil Rytarowski wrote: > Upstream libc++ maintainers are against patching libc++. I'm buffled how you are arriving at this conclusion. Let me reiterate: STOP MESSING UP THE TREE. Joerg

Re: getrandom and getentropy

On Fri, May 01, 2020 at 07:19:09PM +, Taylor R Campbell wrote: > I propose that we additionally adopt getrandom and getentropy, two C > APIs the world is converging on. For getentropy, this can be a simple > userland wrapper in libc; for getrandom, this requires a new path into > the kernel,

Re: getrandom and getentropy

On Wed, May 13, 2020 at 12:19:06PM +0300, Andreas Gustafsson wrote: > Joerg Sonnenberger wrote: > > On Tue, May 12, 2020 at 04:59:52PM +0300, Andreas Gustafsson wrote: > > > I don't particularly care if we require 100 or 384 bits of estimated > > > entropy,

Re: getrandom and getentropy

On Tue, May 12, 2020 at 04:59:52PM +0300, Andreas Gustafsson wrote: > I don't particularly care if we require 100 or 384 bits of estimated > entropy, nor do I particularly care if the entropy estimate of a > keystroke timestamp is 0 or 1 bit. But I do very much care that if I > accidentally try

Re: posix_spawnp() and PATH - change code or manual ?

On Wed, May 06, 2020 at 10:03:54PM +0700, Robert Elz wrote: > | We have a summer of code project that can cover this part. > > Thanks for the info, which project is that, and who is mentoring it, > if you know? (I am woefully ignorant of everything related to GSoC). See

Re: getrandom and getentropy

On Sun, May 10, 2020 at 02:24:00PM +0300, Andreas Gustafsson wrote: > The getentropy() man pages on OpenBSD, FreeBSD, and Linux all say it > returns "high-quality" entropy, and do not caution against using it > for security critical purposes such as key generation, so presumably > applications do

Re: PATCH libatomic

On Sun, May 10, 2020 at 06:16:49PM +0200, Kamil Rytarowski wrote: > On 08.05.2020 21:33, m...@netbsd.org wrote: > > On Fri, May 08, 2020 at 04:09:02PM +0200, Kamil Rytarowski wrote: > >> I object to opinions that libatomic is generally broken, if that would > >> be the cause, it wouldn't be

Re: PATCH libatomic

On Sun, May 10, 2020 at 10:03:27PM +0200, Jaromír Doleček wrote: > Le dim. 10 mai 2020 à 20:25, Joerg Sonnenberger a écrit : > > I find it funny that you pick an example where correctly working > > atomic implementation is essential and where the only reason it is > > pull

Re: PATCH libatomic

On Mon, May 11, 2020 at 01:11:32AM +0200, Kamil Rytarowski wrote: > On 10.05.2020 18:38, Kamil Rytarowski wrote: > > LLDB will be patched to avoid atomics. > I have checked LLDB and std::atomic is used on purpose and was > switched from mutexes 3 years ago. > >

Re: PATCH libatomic

On Thu, May 07, 2020 at 10:49:39PM +, m...@netbsd.org wrote: > I am under the impression that (at least GCC) compilers will not emit > intrinsic calls if they are guaranteed to be available on the target. This is true, but only a minor complication compared to the rest. Joerg

Re: PATCH libatomic

On Fri, May 08, 2020 at 02:44:14PM +0200, Martin Husemann wrote: > On Fri, May 08, 2020 at 02:26:45PM +0200, Kamil Rytarowski wrote: > > With _Atomic() we can mark any arbitrary struct to have serialized > > accesses. As I said, with your attitude we shall remove FPU support (and > > softfloat) as

  1   2   >