Jean-Baptiste Boric | 29 Mar 14:38 2015

Re: GSoC ATF test results statistics project

2015-03-22 23:41 GMT+01:00 Gavin Atkinson <gavin <at>>:
> I hope ythe list doesn't mind me posting here.  FreeBSD has been accepted
> in GSoC this year, and we use the Kyua test framework too.  If you (or
> indeed others) would be interested in working on a project that would
> produce something working on both FreeBSD and NetBSD, you are welcome to
> apply to work with us - there may even be a possibility of joint
> mentorship with somebody from NetBSD if a suitable metor could be found
> and if that would make sense.
> Thanks,
> Gavin

Well, the list itself didn't mind, but Gmail's spam filter did. I
noticed your message only now, and it's way too late to register.


If time allows and nobody steps in until then, I'll give it a try this summer.

Emmanuel Dreyfus | 26 Mar 15:13 2015

malloc, thread and alignment


jemmaloc(3) says:
  Allocations are packed tightly together, which can be an issue for multi-
  threaded applications.  If you need to assure that allocations do not
  suffer from cache line sharing, round your allocation requests up to the
  nearest multiple of the cache line size.

Do we are example of how it should be done? I do not know how to discover
cache line size, neither do I know how I can specify alignment based on it.


Emmanuel Dreyfus
manu <at>

matthew sporleder | 25 Mar 20:01 2015

Re: service(8): post commit feedback solicited

On Wed, Mar 25, 2015 at 11:36 AM, Adrian Steinmann <ast <at>> wrote:
> On Wed, Mar 25, 2015 at 09:56:26AM -0400, matthew sporleder wrote:
>> On Mon, Mar 23, 2015 at 4:26 PM, Adrian Steinmann <ast <at>> wrote:
> ... service(8) manpage elided ...
>> Is this supposed to work on -6?
> Well I didn't test it on -6, neither did I request a pullup-6 (but a pullup-7, where it works unchanged).
>> I can't seem to produce any output.
> I could imagine that $rc_directories is not defined in /etc/defaults/rc.conf:
> rc_directories=/etc/rc.d
> should be there.
> If it's not (I don't have access to a -6 machine ATM), try putting that line into your /etc/rc.conf or:
> [ -z "rc_directories" ] && rc_directories=/etc/rc.d
> right after the getopts in the service script itself.
> If that doesn't work, send me a
> sh -x services -ev >services_out_err_on_6 2>&1
> output under private email.
> Thanks
> Adrian
> PS. This doesn't mean I intend to pullup-6, but it'd be nice to have it work anyways.
(Continue reading)

Adrian Steinmann | 23 Mar 21:26 2015

service(8): post commit feedback solicited

[I know, this should have done _before_ putting it into the tree.]

So the question is: Does someone have strong arguments against
having this shell script to manage the rc scripts? FreeBSD has it
since version 7 and it has not changed much during those years. It
actually has more bells and whistles (i.e. higher TCO). Most linuxes
have something similar. In sum, most admins expect service to manage
the startup scripts.

Our version honors the $rc_directories variable and takes the -e
(enabled) and -l (list all) options.

$ service
usage: service [-elv]
       service [-ev] rc_script_name [rc_script_name2 [...]]
       service [-v] rc_script_name action
       -e: List enabled scripts; check if given scripts are enabled
       -l: List all scripts in rcorder
       -v: Verbose (mention in which directory script is found)
rc_directories is currently set to /etc/rc.d

$ man service

     service — run or list system services

     service [−elv]
     service [−ev] rc_script_name [rc_script_name2 [...]]
     service [−v] rc_script_name action
(Continue reading)

Emmanuel Dreyfus | 19 Mar 05:43 2015

dlopen(3) and symbol conflicts


I use dlopen(3) to load a, which depends on The
later embeds its own uuid_compare symbol which is binary incompatible
with NetBSD's libc uuid_compare. The thing explodes because when I call
uuid_compare(), the libc version is used insteadof's

The problem is specific to dlopen(3): when linking at build time, libc's
uuid_compare is overriden and everything goes fine. Is it a problem on
how is linked? Or how dlopen() is invoked? Or a bug in dlopen(3)?

$ ldd
        -lgfapi.0 => /autobuild/install/lib/
        -lgfrpc.0 => /autobuild/install/lib/
        -lexecinfo.0 => /usr/lib/
        -lelf.1 => /usr/lib/
        -lgcc_s.1 => /usr/lib/
        -lc.12 => /usr/lib/
        -lglusterfs.0 => /autobuild/install/lib/
        -lz.1 => /usr/lib/
        -lrt.1 => /usr/lib/
        -lintl.1 => /usr/lib/
        -lpthread.1 => /usr/lib/
        -lcrypto.8 => /usr/lib/
        -lcrypt.1 => /lib/
        -lgfxdr.0 => /autobuild/install/lib/

$ nm /autobuild/install/lib/|grep uuid_compare 
00067c20 T uuid_compare
(Continue reading)

Emmanuel Dreyfus | 18 Mar 09:48 2015

Re: [PATCH] Re: iflag/oflag for dd(1), round 3


After a few off-list exchanges, here is the patch I am about to commit.


Emmanuel Dreyfus
manu <at>

Kamil Rytarowski | 17 Mar 23:56 2015

reallocarr(3) cleanup


I'm attaching a patch with reallocarr{.ay}(3) cleanup:
- merge reallocarr.3 to malloc.3 for consistency,
- make the reallocarr(3) documentation more detailed,
- write history in malloc.3 of function allocations,
- add in malloc.3 warning about possible overflows,
- add erallocarr(3) to libutil,
- add missing Id tag to reallocarray.c,
- sync reallocarr prototype with documentation (num -> number),
- note that reallocarr first appeared in .Nx 8 not 7 (am I right about it?).

Please review the English correctness.

src/lib/libc/stdlib/reallocarray.3 is without licensing notes! please add it.

CC: authors of the new function.

Thank you for your time!

Emmanuel Dreyfus | 16 Mar 05:08 2015

iflag/oflag for dd(1)


Linux's dd(1) has iflag and oflag operands to specify the O_* flags that
should be given to open(2) for the input and output file. It works like

dd if=in.txt of=out.txt oflag=direct,sync

That tells out.txt should be open with O_RW|O_DIRECT|O_SYNC

There is the question on how to cope with existing behavior. IMO it
should behave like this:

1) iflag should completely override default O_RDONLY for input open

2) oflag should only overring O_CREAT in default output open flags:
O_RW | O_CREAT | (ddflags & (C_SEEK | C_NOTRUNC) ? 0 : O_TRUNC))
it should become:
O_RW | oflag | (ddflags & (C_SEEK | C_NOTRUNC) ? 0 : O_TRUNC))
with unspecifield oflag being set to O_CREAT

Anyone against adding the feature? I can craft a patch if it is


Emmanuel Dreyfus
manu <at>

(Continue reading)

Kamil Rytarowski | 16 Mar 01:58 2015

New function: consttime_memcmp(3)


I'm attaching a patch against current adding a new libc and
kernel function: consttime_memcmp(3). The code is borrowed
from OpenBSD timingsafe_memcmp(3) [1].

consttime_memcmp(3) is similar to memcmp(3) with timing safe layer.
For details please see below at the preprocessed man-page.

The patch is modeled after consttime_memequal(3).
Please review and import into .Nx 8.

CONSTTIME_MEMCMP(3)        Library Functions Manual        CONSTTIME_MEMCMP(3)

     consttime_memcmp -- compare byte strings without timing leaks

     Standard C Library (libc, -lc)

     #include <string.h>

     consttime_memcmp(void *b1, void *b2, size_t len);

     The consttime_memcmp() function compares byte string b1 against byte
     string b2.  Both strings are assumed to be len bytes long.

(Continue reading)

Kamil Rytarowski | 10 Mar 13:39 2015

Resolve another incompatibility of strtonum(3) with OpenBSD


In the next round of patches I start with a change to the implementation of strtonum(3).
Our strtonum(3) accepts base 0, OpenBSD sticks to 10.

The attached patch will fix it.

In the regard the pending libc patches for strtonum(3) / strtoi(3) in the field of:
- documentation,
- tests,
- use.

The mentioned patches are listed at:

Thank you for your time!
Attachment (patch-strtonum): application/octet-stream, 498 bytes
Joerg Sonnenberger | 8 Mar 20:48 2015

Re: pwait(1) added

On Sat, Mar 07, 2015 at 07:08:53PM -0500, James K. Lowden wrote:
> On Fri, 6 Mar 2015 13:16:18 +0100
> Joerg Sonnenberger <joerg <at>> wrote:
> > > Taking the second problem first, ISTM that doesn't require anything
> > > fancy but requires information of what's "expected".  If you build a
> > > database of successful build-times, then cancelling stalled builds
> > > could surely be accomplished by enregistering the start of each
> > > package's build process, and periodically patrolling the tree for
> > > cases when ".done" or whatever wasn't produced in the expected
> > > time.  
> > 
> > Problem with such databases is that they need maintainance, explosions
> > in build time are not uncommon, even more on transistions from failure
> > to success. That's what makes the "doesn't make progress for a while"
> > metric so interesting -- it can work reliably without knowing anything
> > about the build in advance.
> So, IIUC, what you're saying is that you'd like to monitor the build
> process and take note of ... what?  "Doesn't make progress" isn't
> interesting; it's impossible because too vague.  The process is doing
> something.  Are you going to assume that because there's no I/O after N
> minutes that the process is stalled?  

We already have a measure to terminate processes that "do something",
ulimit -t. So if the process is actually using CPU time, it can be
killed without manual intervention. I'm also not really concerned about
fork bombs, I haven't seen such a problem yet. What I have seen is
processes stuck waiting for something to happen. That can be a kind of
zombie with the wrong PID or a dead lock in a multi-threaded program
(Continue reading)